Je dois fournir des données en temps réel ou presque en temps réel pour les rapports SSRS et Tableau. Je ne veux pas que le système OLTP de production soit affecté négativement par des requêtes de longue durée. L'exécution d'une requête volumineuse sur une base de données secondaire dans un groupe de disponibilité affectera-t-elle les performances des transactions dans la base de données principale?
Réponses:
L'exécution d'une requête volumineuse sur une base de données secondaire dans un groupe de disponibilité affectera-t-elle les performances des transactions dans la base de données principale?
Cela dépend du mode de synchronisation que vous avez utilisé lors de la configuration du groupe de disponibilité - Sync ou Async!
Sur la réplique secondaire , toutes les transactions utilisent UNIQUEMENT le niveau d'isolement de l'instantané et toutes les indications de verrouillage sont également ignorées. C'est pourquoi il est important de tester votre charge de travail lorsque vous adoptez AlwaysON.
Bien que le mappage de la charge de travail de génération de rapports vers l'isolement de capture instantanée élimine le blocage entre la charge de travail DML appliquée par le thread REDO sur la réplique secondaire et la charge de travail de lecture ou de rapport, il n'élimine pas le blocage potentiel du thread REDO lors de l'exécution d'une opération DDL .
Si vous utilisez
Mode synchrone
Un problème de blocage sur votre réplique secondaire aura un impact sur les performances de vos requêtes sur la réplique principale. Ainsi, une charge de travail de lecture (sélection) exécutée sur le secondaire peut empêcher le thread de rétablissement d'appliquer les modifications provenant du réplica principal. Cela signifie que le réplica principal doit attendre que les modifications soient appliquées à tous les réplicas SYNC secondaires avant de s'engager localement et peut se terminer par des délais d'expiration ou un blocage ou un blocage.
Le thread REDO peut être vu sur le secondaire lisible comme la DB STARTUPcommande dans sys.dm_exec_requests. Si ce thread est bloqué, votre charge de travail de lecture sur le secondaire pourrait avoir un impact sur le principal.
Pour plus de détails, vérifiez - Scénario 1: REDO bloqué en raison d'une requête importante sur la réplique secondaire
Mode asynchrone
Votre définition de «en temps réel ou presque en temps réel» nécessite plus de réflexion en gardant à l'esprit la méthode de synchronisation utilisée, la latence du réseau et le niveau d'occupation de la réplique principale et l'activité du journal qui doit être transportée de manière secondaire.
SQL Server 2016 a apporté quelques améliorations majeures dans le domaine AlwaysON, par exemple