L'esecuzione di una query di grandi dimensioni su un database secondario in un gruppo di disponibilità influirà sulle prestazioni della transazione nel database primario?

Devo fornire dati in tempo reale, o quasi in tempo reale, per i report SSRS e Tableau. Non voglio che il sistema OLTP di produzione sia influenzato negativamente da query di lunga durata. L'esecuzione di una query di grandi dimensioni su un database secondario in un gruppo di disponibilità influirà sulle prestazioni della transazione nel database primario?

L'esecuzione di una query di grandi dimensioni su un database secondario in un gruppo di disponibilità influirà sulle prestazioni della transazione nel database primario?

Dipende dalla modalità di sincronizzazione utilizzata durante la configurazione del gruppo di disponibilità - Sincronizza o Asincronizza!

Nella replica secondaria , tutte le transazioni utilizzano SOLO il livello di isolamento dello snapshot e vengono ignorati anche tutti i suggerimenti di blocco. Ecco perché è importante testare il carico di lavoro quando si abbraccia AlwaysON.

Da: Riduzione al minimo del blocco del thread REDO durante l'esecuzione del carico di lavoro dei report sulla replica secondaria

Mentre la mappatura del carico di lavoro di reporting sull'isolamento dello snapshot elimina il blocco tra il carico di lavoro DML applicato dal thread REDO sulla replica secondaria e il carico di lavoro di lettura o reporting, non elimina il potenziale blocco del thread REDO durante l'esecuzione di un'operazione DDL .

Se si utilizza

• Modalità sincrona

  • Il problema di blocco sulla replica secondaria influirà sulle prestazioni delle query sulla replica primaria. Pertanto, un carico di lavoro di lettura (seleziona) eseguito su secondario potrebbe impedire al thread di ripetizione di applicare le modifiche provenienti dalla replica primaria. Ciò significa che la replica primaria deve attendere che le modifiche vengano applicate a tutte le repliche SYNC secondarie prima di eseguire il commit a livello locale e potrebbe finire in timeout o blocco o deadlock.

    Il thread REDO può essere visto sul Secondario leggibile come DB STARTUPcomando in sys.dm_exec_requests. Se quel thread viene bloccato, il carico di lavoro di lettura sul secondario potrebbe causare un impatto sul primario.

    Per ulteriori dettagli, controllare - Scenario 1: REDO bloccato a causa di una query di grandi dimensioni sulla replica secondaria

• Modalità asincrona

  • Il primario non attende il riconoscimento dal secondario. Un problema di blocco su secondario è solo isolato su secondario in cui la coda di ripetizione crescerà su secondaria fino a quando i blocchi non saranno chiari e il thread di ripetizione sarà in grado di applicare i blocchi di registro. Ciò non influirà sulla replica primaria.

La tua definizione di "in tempo reale o quasi in tempo reale" richiede ulteriori riflessioni tenendo presente il metodo di sincronizzazione utilizzato, la latenza della rete e l'impegno della replica primaria e l'attività di registro che deve essere trasportata secondaria.

SQL Server 2016 ha apportato alcuni importanti miglioramenti nel regno AlwaysON ad es

• Algoritmi di compressione migliorati e compressione parallela dei dati del blocco log
• Miglioramento da 4x a 5x della velocità di trasporto del blocco log
• e molti altri - Funziona più velocemente !