문제 해결: 가용성 그룹 초과 RTO
적용 대상: 
SQL Server
가용성 그룹에서 데이터 손실 없이 자동 장애 조치(failover) 또는 계획된 수동 장애 조치(failover) 후, 장애 조치 시간이 RTO(복구 시간 목표)를 초과합니다. 또는 Always On 가용성 그룹에 대한 성능 모니터링의 방법을 사용하여 동기 커밋 보조 복제본(예: 자동 장애 조치(failover) 파트너)의 장애 조치 시간을 예상할 때 RTO 초과를 발견할 수 있습니다.
자동 장애 조치(failover)가 아직 완료되지 않은 경우 SQL Server 2012 AlwaysOn 환경의 자동 장애 조치(failover) 문제 해결을 참조하세요.
다음 섹션에서는 장애 조치(failover) 시간이 RTO를 초과하게 되는 일반적인 원인을 설명합니다.
다시 실행 스레드의 실행을 차단하는 워크로드 보고
보조 복제본(replica)에 대한 다시 실행 스레드는 장기 실행 읽기 전용 쿼리에 의해 DDL(데이터 정의 언어)을 변경하지 못하도록 차단됩니다.
설명
보조 복제본에서 읽기 전용 쿼리는 스키마 안정성(Sch-S) 잠금을 획득합니다. 이러한 Sch-S 잠금은 다시 실행 스레드가 DDL을 변경하기 위해 스키마 수정(Sch-M) 잠금을 획득하지 못하게 할 수 있습니다. 차단된 다시 실행 스레드는 차단 해제될 때까지 로그 레코드를 적용할 수 없습니다. 차단이 해제된 후에는 로그의 끝까지 따라가고, 후속 실행 취소 및 장애 조치(failover) 프로세스가 계속 진행되도록 할 수 있습니다.
진단 및 해결
다시 실행 스레드가 차단되면 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 리소스를 놓고 경쟁하며 다시 실행 스레드의 속도를 늦출 수 있습니다.
진단 및 해결
다음 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에 미치는 영향을 최소화할 수 있습니다.