MSSQLSERVER_19407

Aplica-se a: SQL Server

Detalhes

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 do 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 AlwaysOn. 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 concessão envolvem problemas em todo o sistema. Aqui está uma lista de possibilidades que podem causar a expiração da concessão e causar uma reinicialização ou failover:

• Alto uso da CPU no sistema (próximo a 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 quorum. Para solucionar problemas de perda de quorum, consulte Configurar e gerenciar quorum e Recuperação de desastre do WSFC por meio de quorum forçado (SQL Server).

• Limitação de VM que afeta o desempenho e causa a expiração da concessão.

• O processo do SQL Server não responde ao gerar um grande despejo de memória. 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 não flexível
  • Tempo limite da trava
  • Agendador de deadlock
  • Deadlock não resolvido

Ação do usuário

Solucionar problemas de alta CPU

1. Abra o Gerenciador de tarefas.

2. Vá para a guia Desempenho e veja se as CPUs estão próximas ou com 100% de utilização.

3. Vá para a guia Processos e classifique os processos pela coluna CPU em ordem decrescente, selecionando na coluna CPU .

4. Identifique o processo que usa a maior parte da CPU e trabalhe para entender e resolver o motivo pelo qual ele está causando a alta CPU.

5. Se o processo for SQL Server, consulte Solucionar problemas de alto uso da CPU no SQL Server.

6. Você pode usar o script do PowerShell a seguir 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:

1. Verifique se há erros no log de eventos do aplicativo ou do sistema como Your system is low on virtual memory. Você pode até ver esse erro exibido na tela se estiver conectado ao servidor.

2. Abra o Gerenciador de tarefas, selecione Desempenho -> Memória para verificar se cerca de 100% por cento da memória está sendo consumida. Use a guia Detalhes para identificar todos os aplicativos que podem ser os maiores consumidores de memória.

3. Como alternativa, você pode usar o Monitor de Desempenho e monitorar esses contadores ao longo do tempo:

   • Processo\Conjunto de Trabalho - para verificar o uso de memória de processos individuais
   • Memória\MBytes disponíveis - para verificar o uso geral da memória no sistema

   Você pode usar o script do PowerShell a seguir para identificar o uso geral de memória em todo o processo e a memória disponível no sistema. Se você quiser 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
       }
   }
   

4. Se você identificar aplicativos específicos que estão consumindo grandes quantidades de memória, considere interromper ou mover esses aplicativos em outro sistema ou controlar o uso de memória.

5. Se o SQL Server estiver consumindo grandes quantidades de memória, você poderá considerar o uso sp_configure 'max server memory' para reduzir o 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 para 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 processo por padrão, para gerar um minidespejo SQLDumper.exe com memória indireta. No entanto, se essa geração de despejo demorar muito, o processo do SQL Server deixará de responder, o que pode disparar um tempo limite de concessão. As causas comuns para um despejo de memória demorar muito incluem:

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

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

• Aumente 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 VM (máquina virtual) para superprovisionamento

Se você estiver usando uma máquina virtual, verifique se não está provisionando ou sobrecarregando CPUs e recursos de memória. O superprovisionamento 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 memória baixa. Freqüentemente, se você estiver exibindo coisas dentro do sistema operacional convidado, explicar por que 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 de processamento, o que provavelmente causará tempos limite de concessão. Para obter mais informações sobre como lidar com o excesso de comprometimento, consulte Solução de problemas de desempenho da máquina virtual ESX/ESXi (2001003) e Virtualização – Comprometimento excessivo de memória e como detectá-la na VM.

Verificar a migração ou o backup da 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 fornecem uma migração quase instantânea. No entanto, se houver afunilamentos de rede ou computador host, essas migrações poderão ser prolongadas, o que fará 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 todos os problemas com a migração da VM antes de resolver problemas de tempo limite de concessão.

As soluções de backup de máquina virtual também podem causar um tempo de inatividade para as VMs. Se um backup de VM estiver sendo feito no sistema operacional host ou qualquer manutenção semelhante for feita no computador host que leva 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 os atrasos causados por backups de VM ou outras manutenções primeiro, antes de examinar os problemas de tempo limite de concessão.