기본 복제본의 변경 내용이 Always On 가용성 그룹의 보조 복제본에 반영되지 않은 이유 확인
적용 대상: 
SQL Server
클라이언트 애플리케이션에서 기본 복제본에 대한 업데이트를 성공적으로 완료하지만 보조 복제본 쿼리는 변경 내용이 반영되지 않았음을 보여줍니다. 이 경우 가용성에 정상 동기화 상태가 있음을 가정합니다. 대부분의 경우 이 동작은 몇 분 후에 저절로 해결됩니다.
몇 분 후에도 보조 복제본 변경 내용이 반영되지 않으면 동기화 작업 흐름에 병목 현상이 발생한 것일 수 있습니다. 병목 상태의 위치는 보조 복제본이 동기 커밋으로 설정되었는지 아니면 비동기 커밋으로 설정되었는지에 따라 달라집니다.
동기 커밋
기본 복제본에 대한 각각의 성공적인 업데이트는 이미 보조 복제본에 동기화되었거나 보조 복제본에서 강화를 위해 로그 레코드가 이미 플러시된 것입니다. 따라서 병목 상태는 보조 복제본에서 로그가 플러시된 후에 발생하는 다시 실행 프로세스에서 나타나야 합니다.
그러나 다시 실행이 캐치업되면 보조 복제본의 모든 읽기 워크로드는 스냅샷 격리됩니다.
기본 복제본의 장기 실행 트랜잭션
보조 복제본에서 다시 실행
비동기 커밋
비동기 커밋은 로컬 디스크로 플러시되는 즉시 트랜잭션을 승인하므로, 해당 시점 이후 어디에서나 병목 상태가 나타날 수 있습니다.
기본 복제본의 장기 실행 트랜잭션
네트워크 대기 시간 또는 처리량
보조 복제본에서 로그 확정
보조 복제본에서 다시 실행
다음 섹션에서는 읽기 전용 쿼리에 대해 기본 복제본의 변경 내용이 보조 복제본에 반영되지 않는 일반적인 원인을 설명합니다.
장기 실행 활성 트랜잭션
기본 복제본의 장기 실행 트랜잭션은 보조 복제본의 업데이트를 읽지 못하게 합니다.
설명
보조 복제본의 모든 읽기 워크로드는 스냅샷 격리 쿼리입니다. 스냅샷 격리에서 읽기 전용 클라이언트는 다시 실행 로그에서 가장 오래된 활성 트랜잭션의 시작 지점에 있는 보조 복제본의 가용성 데이터베이스를 봅니다. 트랜잭션이 몇 시간 동안 커밋되지 않은 경우, 열려 있는 트랜잭션은 모든 읽기 전용 쿼리가 새 업데이트를 보지 못하도록 차단합니다.
진단 및 해결
기본 복제본에서 DBCC OPENTRAN(Transact-SQL)을 사용하여 가장 오래된 활성 트랜잭션을 보고 롤백할 수 있는지 확인합니다. 가장 오래된 활성 트랜잭션이 롤백되고 보조 복제본에 동기화되면, 보조 복제본에서 워크로드를 읽을 경우 가용성 데이터베이스에서 가장 오래된 활성 트랜잭션의 시작 부분까지 업데이트를 볼 수 있습니다.
네트워크 대기 시간이 길거나 네트워크 처리량이 낮으면 기본 복제본에 로그가 쌓입니다.
네트워크 대기 시간이 길거나 처리량이 낮으면 로그가 보조 복제본에 전송되지 않을 수 있습니다.
설명
기본 복제본은 보조 복제본으로 전송된 승인되지 않은 최대 허용 메시지 수를 초과하는 경우 로그 전송에 대한 흐름 제어를 활성화합니다. 이러한 메시지의 일부가 승인될 때까지 로그 블록이 보조 복제본으로 전송될 수 없습니다. 이 상황은 잠재적인 데이터 손실에 더 심각한 영향을 미칠 수 있으며, RPO(복구 지점 목표)를 위태롭게 할 수 있습니다.
진단 및 해결
log_send_queue_size의 DMV 값이 높을 경우, 로그가 기본 복제본에 다시 유지되는 문제를 나타낼 수 있습니다. 이 값을 log_send_rate로 나누면 보조 복제본에서 데이터를 얼마나 빨리 따라잡을 수 있는지를 대략적으로 예측할 수 있습니다.
또한 두 성능 개체 SQL Server: Availability Replica > Flow Control Time (ms/sec) 및 SQL Server: Availability Replica >Flow Control/sec를 확인하는 데 유용합니다. 이러한 두 값을 곱하면 흐름 제어가 해제될 때까지 대기하는 데 소비한 최종 시간이 나타납니다. 흐름 제어 대기 시간이 길수록 전송 속도가 느려질 수 있습니다.
다음은 네트워크 대기 시간 및 처리량을 진단하는 데 유용한 메트릭의 목록입니다. ping.exe와 같은 다른 Windows 도구를 사용하여 네트워크 사용률을 평가할 수 있습니다.
DMV log_send_rate
성능 카운터
SQL Server:Database > Log Bytes Flushed/sec성능 카운터
SQL Server:Database Mirroring > Send/Receive Ack Time성능 카운터
SQL Server:Availability Replica > Bytes Sent to Replica/sec성능 카운터
SQL Server:Availability Replica > Bytes Sent to Transport/sec성능 카운터
SQL Server:Availability Replica > Flow Control Time (ms/sec)성능 카운터
SQL Server:Availability Replica > Flow Control/sec성능 카운터
SQL Server:Availability Replica > Resent Messages/sec
이 문제를 해결하려면 네트워크 대역폭을 업그레이드하거나, 불필요한 네트워크 트래픽을 제거하거나 줄여봅니다.
다시 실행 스레드의 실행을 차단하는 다른 보고 워크로드
보조 복제본(replica)에 대한 다시 실행 스레드는 장기 실행 읽기 전용 쿼리에 의해 DDL(데이터 정의 언어)을 변경하지 못하도록 차단됩니다. 추가 업데이트를 읽기 작업에 사용할 수 있도록 다시 실행 스레드의 잠금을 해제해야 합니다.
설명
보조 복제본에서 읽기 전용 쿼리는 스키마 안정성(Sch-S) 잠금을 획득합니다. 이러한 Sch-S 잠금은 다시 실행 스레드가 DDL을 변경하기 위해 스키마 수정(Sch-M) 잠금을 획득하지 못하게 할 수 있습니다. 차단된 다시 실행 스레드는 차단 해제될 때까지 로그 레코드를 적용할 수 없습니다.
진단 및 해결
다시 실행 스레드가 차단되면 sqlserver.lock_redo_blocked라는 확장 이벤트가 생성됩니다. 또한 보조 복제본에서 DMV sys.dm_exec_request를 쿼리하여 REDO 스레드를 차단하는 세션을 찾은 다음 수정 작업을 수행할 수 있습니다. 다음 쿼리는 다시 실행 스레드를 차단하는 읽기 작업의 세션 ID를 반환합니다.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
다시 실행 스레드가 차단 해제된 보고 워크로드를 완료하도록 하거나 차단 세션 ID에 대해 KILL(Transact-SQL) 명령을 실행하여 다시 실행 스레드를 즉시 차단 해제할 수 있습니다.
리소스 경합으로 인한 다시 실행 스레드 뒤처짐
보조 복제본에 대한 대규모 보고 워크로드로 인해 보조 복제본의 성능이 저하되고 다시 실행 스레드가 뒤쳐졌습니다.
설명
보조 복제본에서 로그 레코드를 적용할 때 다시 실행 스레드는 로그 디스크에서 로그 레코드를 읽은 다음 각 로그 레코드에 대해 데이터 페이지에 액세스하여 로그 레코드를 적용합니다. 페이지가 버퍼 풀에 아직 없는 경우, 페이지 액세스가 I/O 바인딩(실제 디스크에 액세스)될 수 있습니다. I/O 바인딩된 보고 워크로드가 있는 경우, 보고 워크로드는 다시 실행 스레드와 I/O 리소스를 놓고 경쟁하며 다시 실행 스레드의 속도를 늦출 수 있습니다. 이 상황은 업데이트된 데이터를 보는 다른 보고 워크로드에 영향을 미칠 뿐만 아니라 RTO에도 영향을 미칩니다.
진단 및 해결
다음 DMV 쿼리를 사용하여 last_redone_lsn과 last_received_lsn 간의 차이를 측정하여 다시 실행 스레드가 얼마나 뒤처졌는지 확인할 수 있습니다.
select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,
last_redone_lsn, last_redone_time
from sys.dm_hadr_database_replica_states
다시 실행 스레드가 실제로 뒤처진 경우 보조 복제본에 대해 성능 저하의 근본 원인을 조사해야 합니다. 보고 워크로드와의 I/O 경합이 있는 경우 Resource Governor를 사용하여 보고 워크로드에서 사용하는 CPU 주기를 제어함으로써 사용되는 I/O 주기를 어느 정도 간접적으로 제어할 수 있습니다. 예를 들어 보고 워크로드가 CPU의 10%를 사용하지만 워크로드가 I/O에 바인딩된 경우, Resource Governor를 사용하여 CPU 리소스 사용량을 5%로 제한함으로써 읽기 워크로드를 제한하는 방법으로 I/O에 미치는 영향을 최소화할 수 있습니다.