MSSQLSERVER_19407

Van toepassing op:SQL Server

Bijzonderheden

Attribute	Waarde
Productnaam	SQL Server
Gebeurtenis-id	19407
Bron van gebeurtenis	MSSQLSERVER
Onderdeel	SQLEngine
Symbolische naam	HADR_AG_LEASE_EXPIRED
Berichttekst	De lease tussen de beschikbaarheidsgroep '%.*ls' en het failovercluster van Windows Server is verlopen. Er is een verbindingsprobleem opgetreden tussen het exemplaar van SQL Server en het Windows Server-failovercluster. Als u wilt bepalen of de beschikbaarheidsgroep een failover correct uitvoert, controleert u de bijbehorende beschikbaarheidsgroepresource in het Windows Server-failovercluster.

Explanation

Fout 19407 wordt gegenereerd in het SQL Server-foutenlogboek wanneer de communicatie tussen SQL Server en het Windows Server-failovercluster verloren gaat. Normaal gesproken treedt een corrigerende actie op: een failover naar een ander AlwaysOn-knooppunt.

Een lease is een communicatiemechanisme op basis van tijd dat plaatsvindt tussen de SQL Server en het WSFC-proces (Windows Server Failover Cluster), met name het RHS.EXE proces. De twee processen communiceren periodiek met elkaar om ervoor te zorgen dat het andere proces wordt uitgevoerd en reageert. Deze communicatie vindt plaats met behulp van Windows-gebeurtenisobjecten en zorgt ervoor dat een failover van de AG-resource niet plaatsvindt zonder kennis van de WSFC. Als een van de processen niet reageert op de leasecommunicatie op basis van een vooraf gedefinieerde leaseperiode, treedt er een time-out voor de lease op. Zie Mechanica en richtlijnen voor lease-, cluster- en statuscontroletime-outs voor AlwaysOn-beschikbaarheidsgroepen voor gedetailleerde informatie. Zie ook hoe het werkt: Time-out van SQL Server AlwaysOn-lease.

Oorzaken

Omdat Windows-gebeurtenissen lichte synchronisatieobjecten zijn, zijn er relatief weinig externe factoren die deze negatief beïnvloeden. Veelvoorkomende problemen die kunnen leiden tot time-outs voor de lease, hebben betrekking op systeembrede problemen. Hier volgt een lijst met mogelijkheden die het verlopen van de lease kunnen veroorzaken en een herstart of failover kunnen veroorzaken:

Hoog CPU-gebruik op het systeem (dicht bij 100%).
Onvoldoende geheugen: weinig virtueel geheugen en/of een van de processen wordt uitgepaginad.
WSFC gaat offline vanwege quorumverlies. Zie Quorumverlies configureren en beheren en WSFC Disaster Recovery via geforceerde quorum (SQL Server) voor informatie over het oplossen van problemen met quorumverlies.
VM-beperking die van invloed is op de prestaties en waardoor de lease verloopt.
Het SQL Server-proces reageert niet tijdens het genereren van een grote geheugendump. Zie Impact van het genereren van dumps voor meer informatie over het genereren van stackdumps. Het genereren van stackdumps kan om een aantal van de volgende redenen optreden:
- Nonyielding scheduler
- Time-out voor vergrendeling
- Deadlocked scheduler
- Onopgeloste impasse

Gebruikersactie

Problemen met hoog CPU-gebruik oplossen

Open Taakbeheer.
Ga naar het tabblad Prestaties en kijk of CPU's dicht bij of bij 100% gebruik liggen.
Ga naar het tabblad Processen en sorteer processen op de CPU-kolom in aflopende volgorde door de CPU-kolom te selecteren.
Identificeer het proces dat de meeste CPU gebruikt en werk aan het begrijpen en oplossen van de reden hiervoor die de hoge CPU veroorzaakt.
Als het proces SQL Server is, raadpleegt u Problemen met hoog CPU-gebruik in SQL Server oplossen.

U kunt het volgende PowerShell-script gebruiken om te controleren op CPU-gebruik op het systeem.

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

Problemen met weinig geheugen oplossen

Als er sprake is van weinig virtueel of fysiek geheugen op het systeem, kan het SQL Server- of clusterresourcehostserviceproces (RHS.exe) worden uitgepaginad. Als het proces naar de schijf wordt gepaginad, wordt het niet actief uitgevoerd en kan de time-out van de lease worden bereikt door het tijdgeheugen beschikbaar is en het proces virtuele bytes weer in fysiek geheugen worden gepaginad. Weinig virtueel geheugen kan worden veroorzaakt door toepassingen, stuurprogramma's of het besturingssysteem dat het volledige geheugen op het systeem verbruikt. Gebruik de volgende methoden om dit probleem op te lossen:

Controleer het gebeurtenislogboek van de toepassing of het systeem op fouten, zoals Your system is low on virtual memory. Deze fout wordt mogelijk zelfs weergegeven op het scherm als u bent aangemeld bij de server.
Open Taakbeheer, selecteer Prestaties -> Geheugen om te controleren of bijna 100% procent van het geheugen wordt verbruikt. Gebruik het tabblad Details om toepassingen te identificeren die de grootste geheugengebruikers kunnen zijn.
U kunt ook Prestatiemeter gebruiken en deze tellers in de loop van de tijd bewaken:
- Proces\Werkset : het geheugengebruik van afzonderlijke processen controleren
- Geheugen\Beschikbare MBytes : om het totale geheugengebruik op het systeem te controleren
U kunt het volgende PowerShell-script gebruiken om het totale geheugengebruik voor alle processen en het beschikbare geheugen op het systeem te identificeren. Als u het geheugengebruik van afzonderlijke processen wilt ophalen, wijzigt u dit "\Process(_Total)\Working Set" in "\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
    }
}
```
Als u specifieke toepassingen identificeert die grote hoeveelheden geheugen verbruiken, kunt u overwegen deze toepassingen op een ander systeem te stoppen of te verplaatsen of het geheugengebruik ervan te beheren.
Als SQL Server grote hoeveelheden geheugen verbruikt, kunt u overwegen sp_configure 'max server memory' om het geheugengebruik te verlagen.

Gegevensverzameling prestatiemeter voor CPU, geheugen en schijf

Dit PowerShell-script vereenvoudigt het verzamelen van prestatiemetergegevens (PerfMon) met betrekking tot CPU, geheugen en schijf. Het script is ontworpen om flexibel te zijn, waardoor aanpassingen mogelijk zijn voor zowel standaard- als benoemde exemplaren van 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

Grote geheugendumps van het SQL Server- of clusterproces verminderen of voorkomen

In sommige gevallen kan het SQL Server-proces uitzonderingen, asserties, scheduler-problemen, enzovoort tegenkomen. In die gevallen activeert SQL Server het SQLDumper.exe proces standaard om een minidump met indirect geheugen te genereren. Als het genereren van die dump echter lang duurt, reageert het SQL Server-proces niet meer, waardoor er mogelijk een time-out voor de lease wordt geactiveerd. Veelvoorkomende oorzaken voor een geheugendump duren onder andere:

groot geheugengebruik door het proces
het I/O-subsysteem waarin de dump wordt geschreven, traag is
de standaardinstelling is gewijzigd van minidump naar een gefilterde of volledige dump

Gebruik de volgende stappen voor AG-systemen om een time-out voor lease te voorkomen:

Sessietime-out verhogen, bijvoorbeeld 120 seconden voor alle replica's
De automatische failover van alle replica's wijzigen in handmatige failover
Verhoog de LeaseTimeout naar 60.000 ms (60 seconden) en wijzig HealthCheckTimeout in 90.000 ms (90 seconden)

Zie Het hulpprogramma Sqldumper.exe gebruiken voor het genereren van een dumpbestand in SQL Server voor meer informatie.

Controleer de configuratie van de virtuele machine (VM) op overprovisioning

Als u een virtuele machine gebruikt, moet u ervoor zorgen dat u CPU's en geheugenresources niet te veel inrichting of overtoewijzing uitvoert. Het overprovisionen van CPU's of geheugen kan ertoe leiden dat het gastbesturingssysteem geen resources meer heeft en dezelfde problemen weergeeft die eerder zijn beschreven: een hoog CPU- en weinig geheugen. Vaak als u dingen in het gastbesturingssystemen bekijkt, waarin wordt uitgelegd waarom u geen rekenresources meer hebt, omdat er dingen gebeuren buiten de virtuele machine zelf. Het overcommitteren van resources kan tijdelijke onderbrekingen van de verwerking veroorzaken, wat waarschijnlijk time-outs voor de lease veroorzaakt. Zie ESX/ESXi-prestatieproblemen (2001003) en Virtualisatie: overtoewijzing van geheugen oplossen en hoe u dit kunt detecteren in de VIRTUELE machine voor meer informatie over het oplossen van overtoewijzing.

Controleren op migratie of back-up van virtuele machines (VM's)

Hyper-V-, VMware- en andere VM-oplossingen bieden de mogelijkheid om VM's te verplaatsen tussen hostmachines (Hyper-V livemigratie en VMware vMotion). In de meeste gevallen bieden deze technologieën een bijna onmiddellijke migratie. Als er echter knelpunten zijn in het netwerk of de hostcomputer, kunnen deze migraties worden verlengd, waardoor de VIRTUELE machine een onderbroken, niet-operationele status heeft. Dit kan leiden tot het verlopen van de leasetime-out tussen SQL Server en de clusterprocessen. Los eventuele problemen met de VM-migratie eerst op voordat u time-outproblemen met leases oplost.

Back-ups van virtuele machines kunnen ook downtime veroorzaken voor VM's. Als er een back-up van een VM wordt gemaakt bij het hostbesturingssysteem of een vergelijkbaar onderhoud wordt uitgevoerd op de hostcomputer die lang duurt, kan dit leiden tot een time-outprobleem bij de lease. De reden hiervoor is dat de SQL Server- en clusterprocessen niet met elkaar kunnen communiceren op de onderbroken VM terwijl de klok tikt. Los eventuele vertragingen op die worden veroorzaakt door back-ups van vm's of ander onderhoud, voordat u time-outproblemen met leases bekijkt.

Feedback

Is deze pagina nuttig?

Last updated on 2026-02-06