可用性グループのセカンダリデータベースで大きなクエリを実行すると、プライマリデータベースのトランザクションパフォーマンスに影響がありますか？

Question

SSRSとTableauのレポート用に、リアルタイムまたはほぼリアルタイムのデータを提供する必要があります。実稼働のOLTPシステムが長時間実行されるクエリによって悪影響を受けることを望まない。可用性グループのセカンダリデータベースで大きなクエリを実行すると、プライマリデータベースのトランザクションパフォーマンスに影響するか？

Kin Shah · Accepted Answer

可用性グループのセカンダリデータベースで大きなクエリを実行すると、プライマリデータベースのトランザクションパフォーマンスに影響がありますか？

それは可用性グループを構成するときに使用した同期モードに依存します-同期または非同期！

セカンダリレプリカでは、すべてのトランザクションがスナップショット分離レベルのみを使用し、すべてのロックヒントも無視されます。そのため、AlwaysONを採用する場合は、ワークロードをテストすることが重要です。

From：セカンダリレプリカでレポートワークロードを実行しているときのREDOスレッドのブロッキングの最小化

レポートワークロードをスナップショット分離にマッピングすると、セカンダリレプリカのREDOスレッドによって適用されるDMLワークロードと読み取りまたはレポートワークロードの間のブロッキングが排除されますが、REDOスレッドの潜在的なブロッキングは排除されません。 DDL操作を実行しています。

使用する場合

同期モード
- セカンダリレプリカでのブロッキングの問題は、プライマリレプリカでのクエリのパフォーマンスに影響します。そのため、セカンダリで実行された読み取りワークロード（選択）によって、REDOスレッドがプライマリレプリカからの変更を適用できなくなる可能性があります。これは、プライマリレプリカがローカルでコミットする前にすべてのセカンダリSYNCレプリカに変更が適用されるのを待たなければならないことを意味し、タイムアウトまたはブロッキングまたはデッドロックになる可能性があります。
  
  REDOスレッドは、読み取り可能なセカンダリでDB STARTUPコマンドsys.dm_exec_requests。そのスレッドがブロックされている場合、セカンダリでの読み取りワークロードがプライマリに影響を与えている可能性があります。
  
  詳細については、チェックシナリオ1：セカンダリレプリカでの大規模なクエリによりREDOがブロックされた
非同期モード
- プライマリはセカンダリからの確認応答を待ちません。セカンダリのブロッキングの問題は、セカンダリに隔離されているだけで、ロックがクリアされ、REDOスレッドがログブロックを適用できるようになるまで、REDOキューはセカンダリで増加します。これはプライマリレプリカには影響しません。

「リアルタイムまたはほぼリアルタイム」の定義では、使用する同期方法、ネットワーク遅延、プライマリレプリカのビジー状態、セカンダリトランスポートする必要のあるログアクティビティに留意しながら、さらに検討する必要があります。

SQL Server 2016では、AlwaysON領域でいくつかの主要な機能強化が行われています。