Чи впливатиме великий запит на вторинній базі даних групи доступності на ефективність транзакцій у первинній базі даних?

Мені потрібно надати дані в режимі реального часу або майже в режимі реального часу для звітів про SSRS та Tableau. Я не хочу, щоб на виробничу систему OLTP негативно впливали тривалі запити. Чи впливатиме великий запит на вторинній базі даних групи доступності на ефективність транзакцій у первинній базі даних?

Чи впливатиме великий запит на вторинній базі даних групи доступності на ефективність транзакцій у первинній базі даних?

Це залежить від режиму синхронізації, який ви використовували при налаштуванні групи доступності - Sync або Async!

На вторинної репліці , всі транзакції використовують Snapshot рівень ізоляції ТІЛЬКИ і все замикаючі підказки ігноруються , а також. Ось чому важливо перевірити своє навантаження під час використання AlwaysON.

Від: Мінімізація блокування потоку REDO під час виконання робочого навантаження звітів у вторинній репліку

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

Якщо використовується

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

  • Проблема з блокуванням вашої вторинної репліки вплине на ефективність ваших запитів щодо первинної репліки. Таким чином, завантажене робоче навантаження читання (select), запущене на вторинному, може заблокувати повторний потік у застосуванні змін, що надходять із первинної репліки. Це означає, що первинна репліка повинна чекати, коли зміни будуть застосовані до всієї вторинної репліки SYNC, перш ніж вона здійсниться локально і може закінчитися тайм-аутами або блокуванням або тупиком блокуванням.

    Потік REDO можна побачити на читаному вторинному як DB STARTUPкоманду в sys.dm_exec_requests. Якщо цей потік заблокований, ваше завантажене читання на вторинному пристрої може спричинити вплив на первинний.

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

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

  • Первинний не чекає підтвердження від вторинного. Проблема блокування для вторинного просто виділяється на вторинну, в якій черга на повторний ріст зростатиме на вторинній, поки блоки не стануть чіткими, і повторна нитка не зможе застосувати блоки журналів. Це не вплине на первинну репліку.

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

SQL Server 2016 зробив деякі основні вдосконалення у царині AlwaysON, наприклад

• Покращені алгоритми стиснення та паралельне стиснення даних блоку журналу
• 4 - 5-кратне покращення пропускної здатності транспортного блоку
• та багато інших - Це просто швидше !