MSSQLSERVER_19407
Gilt für: 
SQL Server
Details
| attribute | Wert |
|---|---|
| Produktname | SQL Server |
| Ereignis-ID | 19407 |
| Ereignisquelle | MSSQLSERVER |
| Komponente | SQLEngine |
| Symbolischer Name | HADR_AG_LEASE_EXPIRED |
| Meldungstext | Die Lease zwischen verfügbarkeitsgruppe '%.*ls' und dem Windows Server-Failovercluster ist abgelaufen. Es ist ein Verbindungsproblem zwischen der SQL Server-Instanz und dem Windows Server-Failovercluster aufgetreten. Um festzustellen, ob die Verfügbarkeitsgruppe ordnungsgemäß fehlschlägt, überprüfen Sie die entsprechende Verfügbarkeitsgruppenressource im Windows Server-Failovercluster. |
Erklärung
Der Fehler 19407 wird im SQL Server-Fehlerprotokoll ausgelöst, wenn die Kommunikation zwischen SQL Server und dem Windows Server-Failovercluster unterbrochen wird. In der Regel tritt eine Korrekturaktion auf – ein Failover auf einen anderen AlwaysOn-Knoten.
Ein Lease ist ein zeitbasierter Kommunikationsmechanismus, der zwischen dem SQL Server- und dem Windows Server-Failoverclusterprozess (WSFC) stattfindet, insbesondere dem RHS.EXE-Prozess. Die beiden Prozesse kommunizieren regelmäßig miteinander, um sicherzustellen, dass der andere Prozess ausgeführt wird und reagiert. Diese Kommunikation erfolgt mithilfe von Windows Event-Objekten und stellt sicher, dass ein Failover der AG-Ressource nicht ohne Kenntnis des WSFC erfolgt. Wenn eines der Prozesse nicht auf die Leasekommunikation basierend auf einem vordefinierten Leasezeitraum reagiert, tritt ein Leasetimeout auf. Ausführliche Informationen finden Sie unter Mechanik und Richtlinien für Lease-, Cluster- und Integritätsprüfungstimeouts für AlwaysOn-Verfügbarkeitsgruppen. Siehe auch How It Works: SQL Server AlwaysOn Lease Timeout
Ursachen
Da Windows-Ereignisse leichte Synchronisierungsobjekte sind, gibt es relativ geringe Anzahl externer Faktoren, die sie negativ beeinflussen. Typische Probleme, die zu Leasetimeouts führen können, umfassen systemweite Probleme. Hier ist eine Liste der Möglichkeiten, die einen Leaseablauf verursachen und einen Neustart oder Failover verursachen können:
Hohe CPU-Auslastung auf dem System (nahe 100%).
Nicht genügend Arbeitsspeicher – geringer virtueller Arbeitsspeicher und/oder eines der Prozesse wird ausgelagert.
WSFC wird aufgrund eines Quorumverlusts offline. Informationen zur Problembehandlung bei Quorumverlusten finden Sie unter Konfigurieren und Verwalten des Quorums und der WSFC-Notfallwiederherstellung über erzwungenes Quorum (SQL Server).
VM-Drosselung wirkt sich auf die Leistung aus und verursacht den Ablauf des Leases.
Der SQL Server-Prozess reagiert nicht beim Generieren eines großen Speicherabbilds. Weitere Informationen zur Stapelabbildgenerierung finden Sie unter "Auswirkungen der Dumpgenerierung". Die Stapelabbildgenerierung kann aus einigen der folgenden Gründe auftreten:
- Nicht ielding scheduler
- Timeout für Latch
- Deadlocked Scheduler
- Nicht aufgelöster Deadlock
Aktion des Benutzers
Behandeln von Problemen mit hoher CPU
Öffnen Sie den Task-Manager.
Wechseln Sie zur Registerkarte "Leistung ", und überprüfen Sie, ob CPUs nahe oder bei einer Auslastung von 100 % liegen.
Wechseln Sie zur Registerkarte "Prozesse ", und sortieren Sie Prozesse nach der CPU-Spalte in absteigender Reihenfolge, indem Sie die CPU-Spalte auswählen.
Identifizieren Sie den Prozess, der die meisten CPU verwendet, und arbeiten Sie daran, den Grund dafür zu verstehen und aufzulösen, warum er die hohe CPU verursacht.
Wenn der Prozess SQL Server ist, lesen Sie die Problembehandlung bei problemen mit hoher CPU-Auslastung in SQL Server.
Sie können das folgende PowerShell-Skript verwenden, um die CPU-Auslastung auf dem System zu überprüfen.
Get-Counter -Counter "\Processor(_Total)\% Processor Time" -SampleInterval 5 -MaxSamples 30 | Select-Object -ExpandProperty CounterSamples | Select-Object TimeStamp, Path, CookedValue
Behandeln von Problemen im Zusammenhang mit wenig Arbeitsspeicher
Wenn es Vorkommen von geringem virtuellen oder physischen Arbeitsspeicher auf dem System gibt, kann der SQL Server- oder clusterressourcenhostdienst (RHS.exe)-Prozess ausgelagert werden. Wenn der Prozess auf den Datenträger ausgelagert wird, wird er nicht aktiv ausgeführt, und das Leasetimeout wird möglicherweise durch den verfügbaren Zeitspeicher erreicht, und die virtuellen Bytes des Prozesses werden wieder in den physischen Speicher verschoben. Geringer virtueller Speicher kann durch Anwendungen, Treiber oder das Betriebssystem verursacht werden, die den gesamten Arbeitsspeicher auf dem System verbrauchen. Verwenden Sie die folgenden Methoden, um dieses Problem zu beheben:
Überprüfen Sie das Anwendungs- oder Systemereignisprotokoll auf Fehler wie
Your system is low on virtual memory. Möglicherweise wird dieser Fehler sogar auf dem Bildschirm angezeigt, wenn Sie beim Server angemeldet sind.Öffnen Sie den Task-Manager, wählen Sie "Leistung> " aus, um zu überprüfen, ob nahe 100 % des Arbeitsspeichers verbraucht werden. Verwenden Sie die Registerkarte "Details", um anwendungen zu identifizieren, die möglicherweise die größten Speicherverbraucher sind.
Alternativ können Sie Leistungsmonitor verwenden und diese Leistungsindikatoren im Laufe der Zeit überwachen:
- Prozess\Arbeitssatz – zur Überprüfung der Speicherauslastung einzelner Prozesse
- Memory\Available MBytes – to check overall memory usage on the system
Sie können das folgende PowerShell-Skript verwenden, um die gesamte Speicherauslastung für alle Prozesse und den verfügbaren Arbeitsspeicher auf dem System zu identifizieren. Wenn Sie die Speicherauslastung einzelner Prozesse erhalten möchten, ändern Sie sie
"\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 } }Wenn Sie bestimmte Anwendungen identifizieren, die große Speichermengen belegen, sollten Sie diese Anwendungen auf einem anderen System beenden oder verschieben oder deren Speicherauslastung steuern.
Wenn SQL Server große Speichermengen verbraucht, können Sie die
sp_configure 'max server memory'Speicherauslastung verringern.
Leistungsmonitor Datensammlung für CPU, Arbeitsspeicher und Datenträger
Dieses PowerShell-Skript erleichtert die Sammlung von Leistungsmonitordaten (PerfMon) in Bezug auf CPU, Arbeitsspeicher und Datenträger. Das Skript ist so konzipiert, dass es flexibel ist, sodass Anpassungen sowohl für Standardinstanzen als auch für benannte Instanzen von SQL Server möglich sind.
#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
Reduzieren oder Vermeiden großer Speicherabbilder des SQL Server- oder Clusterprozesses
In einigen Fällen kann der SQL Server-Prozess Ausnahmen, Assertionen, Zeitplanprobleme usw. auftreten. In diesen Fällen löst SQL Server den SQLDumper.exe Prozess standardmäßig aus, um einen Minidump mit indirektem Speicher zu generieren. Wenn diese Dumpgenerierung jedoch lange dauert, reagiert der SQL Server-Prozess nicht mehr, wodurch ein Leasetimeout ausgelöst wird. Häufige Ursachen für ein Speicherabbild umfassen:
- Große Speicherauslastung durch den Prozess
- das E/A-Subsystem, bei dem das Dump geschrieben wird, langsam ist
- Die Standardeinstellung wurde von Miniabbild zu einem gefilterten oder vollständigen Dump geändert.
Um einen Leasetimeout zu vermeiden, führen Sie die folgenden Schritte auf AG-Systemen aus:
- Sitzungstimeout erhöhen, z. B. 120 Sekunden für alle Replikate
- Ändern des automatischen Failovers aller Replikate in manuelles Failover
- Erhöhen Sie das LeaseTimeout auf 60.000 ms (60 Sekunden) und ändern Sie HealthCheckTimeout auf 90.000 ms (90 Sekunden)
Weitere Informationen finden Sie unter Verwenden des tools Sqldumper.exe zum Generieren einer Abbilddatei in SQL Server.
Überprüfen der Vm-Konfiguration (Virtual Machine) auf Die Überteilung
Wenn Sie einen virtuellen Computer verwenden, stellen Sie sicher, dass Sie keine CPUs und Speicherressourcen überschreiben oder außer Kraft setzen. Das Überschreiben von CPUs oder Arbeitsspeicher kann dazu führen, dass das Gastbetriebssystem nicht mehr Ressourcen enthält und die gleichen Probleme anzeigt, die zuvor beschrieben wurden – hohe CPU und geringer Arbeitsspeicher. Wenn Sie Dinge im Gastbetriebssystem anzeigen, ist es häufig schwierig, zu erklären, warum Computerressourcen auslaufen, da dinge außerhalb des virtuellen Computers selbst passieren. Das Überschreiben von Ressourcen kann zu temporären Unterbrechungen der Verarbeitung führen, was wahrscheinlich zu Leasetimeouts führt. Weitere Informationen zum Beheben von Überlastung finden Sie unter Problembehandlung bei LEISTUNGSproblemen mit ESX/ESXi-Computern (2001003) und Virtualisierung – Überlastung des Arbeitsspeichers und wie sie innerhalb des virtuellen Computers erkannt werden.
Überprüfen der Migration oder Sicherung virtueller Computer (VM)
Hyper-V, VMware und andere VM-Lösungen bieten die Möglichkeit, VMs zwischen Hostcomputern (Hyper-V Live Migration und VMware vMotion) zu verschieben. In den meisten Fällen bieten diese Technologien eine nahezu sofortige Migration. Wenn es jedoch Netzwerk- oder Hostcomputerengpässe gibt, können diese Migrationen verlängert werden, was dazu führt, dass sich der virtuelle Computer in einem angehaltenen, nicht betriebsfähigen Zustand befindet. Dies kann zum Ablauf des Leasetimeouts zwischen SQL Server und den Clusterprozessen führen. Beheben Sie alle Probleme mit der VM-Migration zuerst, bevor Sie Probleme mit dem Leasetimeout beheben.
Sicherungslösungen virtueller Computer können auch zu Ausfallzeiten für virtuelle Computer führen. Wenn eine VM-Sicherung am Hostbetriebssystem ausgeführt wird oder eine ähnliche Wartung auf dem Hostcomputer durchgeführt wird, der sehr lange dauert, kann dies zu einem Timeoutproblem führen. Der Grund dafür ist, dass während der Takt tickt, die SQL Server- und Clusterprozesse nicht auf dem angehaltenen virtuellen Computer miteinander kommunizieren können. Beheben Sie alle Verzögerungen, die durch VM-Sicherungen oder andere Wartungen verursacht werden, bevor Sie Leasetimeoutprobleme untersuchen.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für