SSRS 및 Tableau보고를 위해 실시간 또는 거의 실시간 데이터를 제공해야합니다. 장기 실행 쿼리로 인해 프로덕션 OLTP 시스템이 부정적인 영향을 받기를 원하지 않습니다. 가용성 그룹의 보조 데이터베이스에서 큰 쿼리를 실행하면 기본 데이터베이스의 트랜잭션 성능에 영향을 줍니까?
답변
가용성 그룹의 보조 데이터베이스에서 큰 쿼리를 실행하면 기본 데이터베이스의 트랜잭션 성능에 영향을 줍니까?
가용성 그룹을 구성 할 때 사용한 동기화 모드 (동기화 또는 비 동기화)에 따라 다릅니다 .
에 보조 복제본 , 모든 트랜잭션 만 해당 스냅 샷 격리 수준을 사용하고 모든 잠금 힌트는도 무시됩니다. 따라서 AlwaysON을 수용 할 때 작업 부하를 테스트하는 것이 중요합니다.
보낸 사람 : 보조 복제본에서보고 작업 부하를 실행할 때 REDO 스레드 차단 최소화
보고 워크로드를 스냅 샷 격리에 매핑하면 보조 복제본의 REDO 스레드에 의해 적용된 DML 워크로드와 읽기 또는보고 워크로드 간의 차단이 제거되지만 DDL 작업을 실행할 때 REDO 스레드의 잠재적 차단은 제거되지 않습니다 .
사용하는 경우
-
동기 모드
-
보조 복제본의 차단 문제는 기본 복제본의 쿼리 성능에 영향을줍니다. 따라서 2 차에서 실행 된 읽기 워크로드 (선택)는 재실행 스레드가 1 차 복제본에서 오는 변경 사항을 적용하지 못하게 할 수 있습니다. 즉, 1 차 복제본은 로컬 2 차 커밋되기 전에 변경 사항이 모든 2 차 SYNC 복제본에 적용될 때까지 기다려야하며 시간 초과 또는 차단 또는 교착 상태로 끝날 수 있습니다.
REDO 스레드는 Readable Secondary에서의
DB STARTUP명령 으로 볼 수 있습니다sys.dm_exec_requests. 해당 스레드가 차단 된 경우 보조 스레드의 읽기 작업 부하가 기본 스레드에 영향을 줄 수 있습니다.자세한 내용 확인- 시나리오 1 : 보조 복제본에 대한 큰 쿼리로 인한 REDO 차단
-
-
비동기 모드
- 기본은 보조의 승인을 기다리지 않습니다. 2 차에서 차단 문제는 2 차로 분리되며 잠금이 해제되고 재실행 스레드가 로그 블록을 적용 할 수있을 때까지 2 차에서 재실행 큐가 커집니다. 기본 복제본에는 영향을 미치지 않습니다.
“실시간 또는 거의 실시간”에 대한 정의는 사용 된 동기화 방법, 네트워크 대기 시간 및 1 차 복제본의 사용량과 2 차로 전송해야하는 로그 활동을 염두에두고 더 많은 생각이 필요합니다.
SQL Server 2016은 AlwaysON 영역에서 몇 가지 주요 개선 사항을 수행했습니다.
- 개선 된 압축 알고리즘 및 로그 블록 데이터의 병렬 압축
- 로그 블록 전송 처리량 4 ~ 5 배 향상
- 그리고 다른 많은 사람들- 그것은 더 빨리 실행됩니다 !