MSSQLSERVER_19407

아티클
04/07/2024

적용 대상: SQL Server

세부 정보

attribute	값
제품 이름	SQL Server
이벤트 ID	19407
이벤트 원본	MSSQLSERVER
구성 요소	SQLEngine
심볼 이름	HADR_AG_LEASE_EXPIRED
메시지 텍스트	가용성 그룹 '%.*ls'과 Windows Server 장애 조치(failover) 클러스터 간의 임대가 만료되었습니다. SQL Server 인스턴스와 Windows Server 장애 조치 클러스터 간에 연결 문제가 발생했습니다. 가용성 그룹이 올바르게 장애 조치되는지 확인하려면 Windows Server 장애 조치 클러스터에서 해당 가용성 그룹 리소스를 확인합니다.

설명

SQL Server와 Windows Server 장애 조치 클러스터 간의 통신이 끊어지면 SQL Server 오류 로그에서 오류 19407이 발생합니다. 일반적으로 다른 Always On 노드로 장애 조치하는 시정 작업이 발생합니다.

임대는 SQL Server와 WSFC(Windows Server 장애 조치 클러스터) 프로세스, 특히 RHS.EXE 프로세스 간에 발생하는 시간 기반 통신 메커니즘입니다. 두 프로세스는 주기적으로 서로 통신하여 다른 프로세스가 실행되고 응답하는지 확인합니다. 이 통신은 Windows 이벤트 개체 를 사용하여 수행되며, WSFC에 대한 지식 없이 AG 리소스의 장애 조치(failover)가 발생하지 않도록 합니다. 프로세스 중 하나가 미리 정의된 임대 기간에 따라 임대 통신에 응답하지 않으면 임대 시간 제한이 발생합니다. 자세한 내용은 Always On 가용성 그룹에 대한 임대, 클러스터 및 상태 검사 시간 제한에 대한 메커니즘 및 지침을 참조하세요. 작동 방식도 참조 하세요. SQL Server AlwaysOn 임대 시간 제한

원인

Windows 이벤트는 경량 동기화 개체이므로 상대적으로 적은 수의 외부 요소가 부정적인 영향을 줍니다. 임대 시간 초과로 이어질 수 있는 일반적인 문제에는 시스템 차원의 문제가 포함됩니다. 다음은 임대 만료를 유발하고 다시 시작 또는 장애 조치(failover)를 일으킬 수 있는 가능성 목록입니다.

시스템의 높은 CPU 사용량(100%에 가깝습니다.)
메모리 부족 조건 - 낮은 가상 메모리 및/또는 프로세스 중 하나가 페이징되고 있습니다.
쿼럼 손실로 인해 WSFC가 오프라인 상태가 됩니다. 쿼럼 손실 문제를 해결하려면 쿼럼 구성 및 관리, 강제 쿼럼을 통한 WSFC 재해 복구(SQL Server)를 참조하세요.
성능에 영향을 미치고 임대 만료를 일으키는 VM 제한입니다.
SQL Server 프로세스는 큰 메모리 덤프를 생성하는 동안 응답하지 않습니다. 스택 덤프 생성에 대한 자세한 내용은 덤프 생성의 영향을 참조 하세요. 스택 덤프 생성은 다음과 같은 몇 가지 이유로 발생할 수 있습니다.
- 비지정 스케줄러
- 래치 시간 제한
- 교착 상태 스케줄러
- 해결되지 않은 교착 상태

사용자 작업

높은 CPU 문제 해결

작업 관리자를 엽니다.
성능 탭으로 이동하여 CPU가 100% 사용률에 가까운지 확인합니다.
프로세스 탭으로 이동하여 CPU 열을 선택하여 CPU 열을 기준으로 프로세스를 내림차순으로 정렬합니다.
대부분의 CPU를 사용하는 프로세스를 식별하고 높은 CPU를 유발하는 이유를 이해하고 해결하는 작업을 수행합니다.
프로세스가 SQL Server인 경우 SQL Server에서 CPU 사용량이 많은 문제 해결을 참조하세요.

다음 PowerShell 스크립트를 사용하여 시스템에서 CPU 사용률을 확인할 수 있습니다.

Get-Counter -Counter "\Processor(_Total)\% Processor Time" -SampleInterval 5 -MaxSamples 30 |
    Select-Object -ExpandProperty CounterSamples | Select-Object TimeStamp, Path, CookedValue

메모리 부족 문제 해결

시스템에 낮은 가상 또는 실제 메모리가 있는 경우 SQL Server 또는 클러스터 리소스 호스트 서비스(RHS.exe) 프로세스를 페이징할 수 있습니다. 프로세스가 디스크에 페이징되는 경우 활성으로 실행되지 않으며 메모리를 사용할 수 있는 시간 및 프로세스 가상 바이트가 실제 메모리로 다시 페이징되는 시간 제한에 도달할 수 있습니다. 낮은 가상 메모리는 시스템에서 전체 메모리를 사용하는 애플리케이션, 드라이버 또는 OS로 인해 발생할 수 있습니다. 이 문제를 해결하려면 다음 방법을 사용합니다.

애플리케이션 또는 시스템 이벤트 로그에서 다음과 같은 Your system is low on virtual memory오류를 확인합니다. 서버에 로그인한 경우 화면에 이 오류가 표시될 수도 있습니다.
작업 관리자를 열고 성능 -> 메모리를 선택하여 메모리의 100% 가까이 사용 중인지 확인합니다. 세부 정보 탭을 사용하여 가장 큰 메모리 소비자가 될 수 있는 애플리케이션을 식별합니다.
또는 성능 모니터 사용하여 시간이 지남에 따라 이러한 카운터를 모니터링할 수 있습니다.
- Process\Working Set - 개별 프로세스 메모리 사용량을 확인합니다.
- Memory\Available MBytes - 시스템의 전체 메모리 사용량을 확인합니다.
다음 PowerShell 스크립트를 사용하여 모든 프로세스의 전체 메모리 사용량과 시스템에서 사용 가능한 메모리를 식별할 수 있습니다. 개별 프로세스 메모리 사용량을 얻으려면 다음으로 "\Process(*)\Working Set"변경 "\Process(_Total)\Working Set" 합니다.
```
$serverName = $env:COMPUTERNAME
$Counters = @(
  ("\\$serverName" + "\Process(_Total)\Working Set") , ("\\$serverName" + "\Memory\Available Bytes")
)

Get-Counter -Counter $Counters -MaxSamples 30 | ForEach-Object {
    $_.CounterSamples | ForEach-Object {
        [pscustomobject]@{
            TimeStamp = $_.TimeStamp
            Path      = $_.Path
            Value_MB  = ([Math]::Round($_.CookedValue, 3)) / 1024 / 1024
        }
        Start-Sleep -s 5
    }
}
```
많은 양의 메모리를 사용하는 특정 애플리케이션을 식별하는 경우 다른 시스템에서 해당 애플리케이션을 중지하거나 이동하거나 해당 메모리 사용량을 제어하는 것이 좋습니다.
SQL Server에서 많은 양의 메모리를 사용하는 경우 메모리 사용량을 줄이는 데 사용할 sp_configure 'max server memory' 수 있습니다.

CPU, 메모리 및 디스크에 대한 데이터 수집 성능 모니터

이 PowerShell 스크립트는 CPU, 메모리 및 디스크와 관련하여 성능 모니터(PerfMon) 데이터 수집을 용이하게 합니다. 이 스크립트는 유연하게 설계되어 SQL Server의 기본 인스턴스와 명명된 인스턴스 모두에 대해 사용자 지정할 수 있습니다.

#Replace with your instance name if need to collect PerfMon data for named instance
$InstanceName = 'MSSQLSERVER'

# Replace with your desired location
$Location = "D:\PerfMonLogs"

# Function to create performance counter log
function Create-PerfCounterLog {
    param
    (
        [string]$InstanceName,
        [string]$Location
    )
    $counters = @(
        '\Memory\*',
        '\PhysicalDisk(*)\*',
        '\LogicalDisk(*)\*',
        '\Server\*',
        '\System\*',
        '\Process(*)\*',
        '\Processor(*)\*',
        '\SQLServer:Databases(*)\*',
        '"\SQLServer:Buffer Manager\*"',
        '"\SQLServer:SQL Statistics\*"',
        '"\SQLServer:Transactions\*"',
        '"\SQLServer:Database Mirroring\*"',
        '"\SQLServer:Latches\*"',
        '"\SQLServer:General Statistics\*"',
        '"\SQLServer:Availability Replica(*)\*"',
        '"\SQLServer:Plan Cache(*)\*"'
    )
    if ($InstanceName -eq 'MSSQLSERVER') {
        # This is for the default SQL Server instance
        $logmanCommand = "logman create counter MS_perf_log -f bin -c $counters"

    }
    else {
        # This is for a named SQL Server instance
        $InstanceName = "MSSQL`$$InstanceName"
        $counters = $counters -replace 'SQLServer', $InstanceName
        $logmanCommand = "logman create counter MS_perf_log -f bin -c $counters"

    }

    $Location = $Location + '\MS_perf_log.blg'
    $logmanCommand += " -si 00:00:01 -max 500 -o $Location"

    Start-Process -FilePath "cmd.exe" -ArgumentList "/c $logmanCommand" -Verb RunAs -Wait

}

# Function to start the collector
function Start-PerfCounterLog {
    Start-Process -FilePath "cmd.exe" -ArgumentList "/c logman start MS_perf_log" -Verb RunAs -Wait
}

# Function to stop and delete the collector
function Stop-Delete-PerfCounterLog {
    Start-Process -FilePath "cmd.exe" -ArgumentList "/c logman stop MS_perf_log" -Verb RunAs -Wait
    Start-Process -FilePath "cmd.exe" -ArgumentList "/c logman delete MS_perf_log" -Verb RunAs -Wait
}

# Create folder if not exists - update the file path as per your environment
$folderPath = $Location
if (-not (Test-Path $folderPath)) {
    New-Item -Path $folderPath -ItemType Directory
}

# Create performance counter log
Create-PerfCounterLog -InstanceName $InstanceName -Location $Location

# Start the collector
Start-PerfCounterLog

# If the event has occurred again and captured, then stop the collector
# Uncomment below line when you want to stop and delete the collector
# Stop-Delete-PerfCounterLog

SQL Server 또는 클러스터 프로세스의 큰 메모리 덤프를 줄이거나 방지합니다.

경우에 따라 SQL Server 프로세스에 예외, 어설션, 스케줄러 문제 등이 발생할 수 있습니다. 이러한 경우 SQL Server는 기본적으로 프로세스를 트리거 SQLDumper.exe 하여 간접 메모리가 있는 미니덤프를 생성합니다. 그러나 해당 덤프 생성에 시간이 오래 걸리는 경우 SQL Server 프로세스는 응답을 중지하여 임대 시간 제한을 트리거할 수 있습니다. 메모리 덤프에 시간이 오래 걸리는 일반적인 원인은 다음과 같습니다.

프로세스별 대용량 메모리 사용량
덤프가 기록되는 I/O 하위 시스템이 느립니다.
기본 설정이 미니 덤프에서 필터링된 덤프 또는 전체 덤프로 변경되었습니다.

임대 시간 제한을 방지하려면 AG 시스템에서 다음 단계를 사용합니다.

세션 시간 제한 늘리기(예: 모든 복제본에 대해 120초)
모든 복제본의 자동 장애 조치(failover)를 수동 장애 조치(failover)로 변경
LeaseTimeout을 60,000ms(60초)로 늘리고 HealthCheckTimeout을 90,000ms(90초)로 변경합니다.

자세한 내용은 Sqldumper.exe 도구를 사용하여 SQL Server에서 덤프 파일을 생성합니다.

오버프로비전에 대한 VM(가상 머신) 구성 확인

가상 머신을 사용하는 경우 CPU 및 메모리 리소스를 과도하게 프로비전하거나 과도하게 커밋하지 않는지 확인합니다. CPU 또는 메모리를 과도하게 프로비전하면 게스트 OS에 리소스가 부족하고 앞에서 설명한 것과 동일한 문제(높은 CPU 및 낮은 메모리)가 표시될 수 있습니다. 게스트 OS 내에서 사물을 보는 경우 가상 머신 자체 외부에서 상황이 발생하므로 컴퓨팅 리소스가 부족한 이유를 설명하는 것이 어려운 경우가 많습니다. 리소스를 과도하게 커밋하면 일시적으로 처리가 중단될 수 있으며 이로 인해 임대 시간 제한이 발생할 수 있습니다. 오버 커밋 을 해결하는 방법에 대한 자세한 내용은 ESX/ESXi 가상 머신 성능 문제 해결(2001003) 및 가상화 – 오버 커밋 메모리 및 VM 내에서 이를 검색하는 방법을 참조하세요.

VM(가상 머신) 마이그레이션 또는 백업 확인

Hyper-V, VMware 및 기타 VM 솔루션은 호스트 컴퓨터 간에 VM을 이동하는 기능을 제공합니다(Hyper-V Live 마이그레이션 및 VMware vMotion). 대부분의 경우 이러한 기술은 거의 즉각적인 마이그레이션을 제공합니다. 그러나 네트워크 또는 호스트 컴퓨터 병목 현상이 있는 경우 이러한 마이그레이션을 연장하여 VM이 일시 중단되고 비작동 상태가 될 수 있습니다. 이로 인해 SQL Server와 클러스터 프로세스 간의 임대 시간 제한 만료가 발생할 수 있습니다. 임대 시간 제한 문제를 해결하기 전에 먼저 VM 마이그레이션과 관련된 문제를 해결합니다.

가상 머신 백업 솔루션으로 인해 VM에 가동 중지 시간이 발생할 수도 있습니다. 호스트 OS에서 VM 백업을 수행하거나 시간이 오래 걸리는 호스트 컴퓨터에서 유사한 유지 관리가 수행되는 경우 임대 시간 제한 문제가 발생할 수 있습니다. 그 이유는 클록이 똑딱거리는 동안 SQL Server 및 클러스터 프로세스가 일시 중단된 VM에서 서로 통신할 수 없기 때문입니다. 임대 시간 제한 문제를 검사하기 전에 먼저 VM 백업 또는 기타 유지 관리로 인한 지연을 해결합니다.

다음을 통해 공유