MSSQLSERVER_19407

Artigo
04/07/2024

Aplica-se a:SQL Server

Detalhes

Atributo	Valor
Nome do produto	SQL Server
ID do evento	19407
Origem do evento	MSSQLSERVER
Componente	SQLEngine
Nome simbólico	HADR_AG_LEASE_EXPIRED
Texto da mensagem	A concessão entre o grupo de disponibilidade '%.*ls' e o Cluster de Failover do Windows Server expirou. Ocorreu um problema de conectividade entre a instância do SQL Server e o Cluster de Failover do Windows Server. Para determinar se o grupo de disponibilidade está fazendo failover corretamente, verifique o recurso de grupo de disponibilidade correspondente no Cluster de Failover do Windows Server.

Explicação

O erro 19407 é gerado no log de erros do SQL Server quando a comunicação entre o SQL Server e o Cluster de Failover do Windows Server é perdida. Normalmente, ocorre uma ação corretiva - um failover para outro nó Always On.

Uma concessão é um mecanismo de comunicação baseado em tempo que ocorre entre o SQL Server e o processo WSFC (Cluster de Failover do Windows Server), especificamente o processo RHS.EXE. Os dois processos se comunicam periodicamente para garantir que o outro processo esteja sendo executado e respondendo. Essa comunicação ocorre usando objetos de Evento do Windows e garante que um failover do recurso AG não ocorra sem o conhecimento do WSFC. Se um dos processos não responder à comunicação de concessão com base em um período de locação predefinido, ocorrerá um tempo limite de locação. Para obter informações detalhadas, consulte Mecânica e diretrizes de tempos limite de concessão, cluster e verificação de integridade para grupos de disponibilidade Always On. Consulte também Como funciona: Tempo limite de concessão AlwaysOn do SQL Server

Causas

Como os Eventos do Windows são objetos de sincronização leves, há um número relativamente pequeno de fatores externos que os afetam negativamente. Problemas típicos que podem levar ao tempo limite de locação envolvem problemas em todo o sistema. Aqui está uma lista de possibilidades que podem causar expiração de concessão e causar uma reinicialização ou failover:

Alto uso da CPU no sistema (perto de 100%).
Condições de falta de memória - pouca memória virtual e/ou um dos processos está sendo paginado.
WSFC ficando offline devido à perda de quórum. Para solucionar problemas de perda de quorum, consulte Configurar e gerenciar quorum e Recuperação de desastres do WSFC por meio de quorum forçado (SQL Server).
Limitação de VM afetando o desempenho e causando expiração de concessão.
O processo do SQL Server não responde durante a geração de um despejo de memória grande. Para obter mais informações sobre a geração de despejo de pilha, consulte Impacto da geração de despejo. A geração de despejo de pilha pode ocorrer por alguns dos seguintes motivos:
- Agendador sem rendimento
- Tempo limite da trava
- Agendador bloqueado
- Deadlock não resolvido

Ação do usuário

Solucionar problemas de CPU alta

Abra o Gerenciador de tarefas.
Vá para a guia Desempenho e veja se as CPUs estão próximas ou com 100% de utilização.
Vá para a guia Processos e classifique os processos pela coluna CPU em ordem decrescente, selecionando na coluna CPU .
Identifique o processo que usa a maioria da CPU e trabalhe para entender e resolver o motivo pelo qual ele causa a CPU alta.
Se o processo for o SQL Server, consulte Solucionar problemas de alto uso de CPU no SQL Server.

Você pode usar o seguinte script do PowerShell para verificar a utilização da CPU no sistema.

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

Solucionar problemas de pouca memória

Se houver ocorrências de pouca memória virtual ou física no sistema, o processo do SQL Server ou do serviço de host de recurso de cluster (RHS.exe) poderá ser paginado. Se o processo for paginado para o disco, ele não será executado ativamente, e o tempo limite de concessão poderá ser atingido no momento em que a memória estiver disponível e os bytes virtuais do processo forem paginados de volta para a memória física. A memória virtual baixa pode ser causada por aplicativos, drivers ou sistema operacional que consomem toda a memória do sistema. Use os seguintes métodos para solucionar esse problema:

Verifique se há erros como o log de eventos do Aplicativo ou do Sistema em busca de erros como Your system is low on virtual memory. Você pode até ver esse erro exibido na tela se estiver conectado ao servidor.
Abra o Gerenciador de tarefas, selecione Desempenho -> Memória para verificar se cerca de 100% da memória está sendo consumida. Use a guia Detalhes para identificar os aplicativos que podem ser os maiores consumidores de memória.
Como alternativa, você pode usar o Monitor de Desempenho e monitorar esses contadores ao longo do tempo:
- Process\Working Set - para verificar o uso de memória de processos individuais
- Memória\MBytes disponíveis - para verificar o uso geral de memória no sistema
Você pode usar o seguinte script do PowerShell para identificar o uso geral de memória em todo o processo e na memória disponível no sistema. Se você gostaria de obter o uso de memória de processos individuais, altere-o "\Process(_Total)\Working Set" para "\Process(*)\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
    }
}
```
Se você identificar aplicativos específicos que estão consumindo grandes quantidades de memória, considere parar ou mover esses aplicativos em outro sistema ou controlar seu uso de memória.
Se o SQL Server estiver consumindo grandes quantidades de memória, você pode considerar o uso sp_configure 'max server memory' para reduzir seu uso de memória.

Coleta de dados do Monitor de Desempenho para CPU, memória e disco

Esse script do PowerShell facilita a coleta de dados do monitor de desempenho (PerfMon) em relação à CPU, memória e disco. O script foi projetado para ser flexível, permitindo a personalização de instâncias padrão e nomeadas do 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

Reduzir ou evitar grandes despejos de memória do SQL Server ou do processo de cluster

Em alguns casos, o processo do SQL Server pode encontrar exceções, declarações, problemas de agendador e assim por diante. Nesses casos, o SQL Server dispara o SQLDumper.exe processo por padrão, para gerar um minidump com memória indireta. No entanto, se essa geração de despejo demorar muito tempo, o processo do SQL Server pára de responder, o que pode disparar um tempo limite de concessão. Causas comuns para um despejo de memória demorar muito tempo incluem:

grande uso de memória pelo processo
o subsistema de E/S onde o despejo é gravado é lento
A configuração padrão foi alterada de minidespejo para um despejo filtrado ou completo

Para evitar um tempo limite de concessão, use as seguintes etapas em sistemas AG:

Aumentar o tempo limite da sessão, por exemplo, 120 segundos para todas as réplicas
Alterar o failover automático de todas as réplicas para failover manual
Aumente o LeaseTimeout para 60.000 ms (60 segundos) e altere HealthCheckTimeout para 90.000 ms (90 segundos)

Para obter mais informações, consulte Usar a ferramenta Sqldumper.exe para gerar um arquivo de despejo no SQL Server.

Verificar a configuração da máquina virtual (VM) quanto ao provisionamento excessivo

Se você estiver usando uma máquina virtual, verifique se não está provisionando ou sobrecomprometendo CPUs e recursos de memória. O provisionamento excessivo de CPUs ou memória pode fazer com que o sistema operacional convidado fique sem recursos e mostre os mesmos problemas descritos anteriormente - CPU alta e pouca memória. Frequentemente, se você estiver visualizando coisas dentro do sistema operacional convidado, explicar por que você está ficando sem recursos de computação é difícil, porque as coisas estão acontecendo fora da própria máquina virtual. O excesso de recursos pode causar interrupções temporárias do processamento, o que provavelmente causará tempos limite de concessão. Para obter mais informações sobre como resolver a superconfirmação, consulte Solucionando problemas de desempenho de máquina virtual (2001003) ESX/ESXi e Virtualização – Sobreconfirmando memória e como detectá-la na VM.

Verificar se há migração ou backup de máquina virtual (VM)

Hyper-V, VMware e outras soluções de VM oferecem a capacidade de mover VMs entre máquinas host (Hyper-V Live Migration e VMware vMotion). Na maioria dos casos, essas tecnologias proporcionam uma migração quase instantânea. No entanto, se houver gargalos de rede ou de máquina host, essas migrações podem ser prolongadas, o que faz com que a VM fique em um estado suspenso e não operacional. Isso pode levar à expiração do tempo limite de concessão entre o SQL Server e os processos de cluster. Resolva quaisquer problemas com a migração de VM primeiro antes de resolver problemas de tempo limite de concessão.

As soluções de backups de máquina virtual também podem causar um tempo de inatividade para VMs. Se um backup de VM estiver sendo feito no sistema operacional host ou qualquer manutenção semelhante for feita na máquina host que leve muito tempo, eles podem levar a um problema de tempo limite de concessão. O motivo é que, enquanto o relógio está correndo, o SQL Server e os processos de cluster não conseguem se comunicar entre si na VM suspensa. Resolva quaisquer atrasos causados por backups de VM ou outras manutenções primeiro, antes de examinar os problemas de tempo limite de concessão.