Повлияет ли выполнение большого запроса на вторичную базу данных в группе доступности на производительность транзакций в первичной базе данных?

Мне нужно предоставлять данные в реальном времени или почти в реальном времени для отчетов SSRS и Tableau. Я не хочу, чтобы на производственную OLTP-систему негативно влияли длительные запросы. Повлияет ли выполнение большого запроса на вторичную базу данных в группе доступности на производительность транзакций в первичной базе данных?

Повлияет ли выполнение большого запроса на вторичную базу данных в группе доступности на производительность транзакций в первичной базе данных?

Это зависит от режима синхронизации, который вы использовали при настройке группы доступности - Sync или Async!

На вторичной реплике , все транзакции используют Snapshot уровень изоляции ТОЛЬКО и все запирающие подсказки игнорируются , а также. Вот почему важно проверять свою рабочую нагрузку при использовании AlwaysON.

От: Минимизация блокировки потока REDO при выполнении рабочей нагрузки отчетов на вторичной реплике

Хотя сопоставление рабочей нагрузки отчетов с изоляцией моментальных снимков устраняет блокировку между рабочей нагрузкой DML, применяемой потоком REDO на вторичной реплике, и рабочей нагрузкой чтения или создания отчетов, она не устраняет потенциальную блокировку потока REDO при выполнении операции DDL .

При использовании

• Синхронный режим

  • Проблема блокировки вторичной реплики повлияет на производительность ваших запросов на первичной реплике. Таким образом, рабочая нагрузка чтения (выборка), запущенная на вторичном сервере, может заблокировать поток восстановления от применения изменений, исходящих от первичной реплики. Это означает, что первичная реплика должна ждать изменений, которые будут применены ко всей вторичной реплике SYNC, прежде чем она будет зафиксирована локально и может закончиться таймаутами, блокировкой или взаимоблокировкой.

    Поток REDO можно увидеть на вторичном компьютере с возможностью чтения как DB STARTUPкоманду в sys.dm_exec_requests. Если этот поток блокируется, то ваша нагрузка чтения на вторичном сервере может оказывать влияние на первичную систему.

    Для получения дополнительной информации проверьте - Сценарий 1: REDO заблокирован из-за большого запроса на вторичной реплике

• Асинхронный режим

  • Основной не ожидает подтверждения от вторичного. Проблема блокировки на вторичном сервере просто изолирована на вторичном, где очередь повторного выполнения будет расти на вторичном сервере до тех пор, пока блокировки не будут сняты и поток повторного выполнения не сможет применить блоки журнала. Это не повлияет на первичную реплику.

Ваше определение «в реальном времени или почти в реальном времени» нуждается в большем внимании с учетом используемого метода синхронизации, задержки в сети и того, насколько занята первичная реплика, и активности журнала, которую необходимо перенести вторично.

SQL Server 2016 сделал несколько важных улучшений в области AlwaysON, например

• Улучшенные алгоритмы сжатия и параллельное сжатие данных блока журнала
• 4–5-кратное улучшение пропускной способности блоков журнала
• и многие другие - это просто быстрее !