MSSQLSERVER_19407

[アーティクル]
04/07/2024

詳細

属性	Value
製品名	SQL Server
イベント ID	19407
イベントソース	MSSQLSERVER
コンポーネント	SQLEngine
シンボル名	HADR_AG_LEASE_EXPIRED
メッセージテキスト	可用性グループ '%.*ls' と Windows Server フェールオーバークラスターの間のリースの有効期限が切れています。 SQL Server のインスタンスと Windows Server フェールオーバークラスターの間で接続の問題が発生しました。可用性グループが正常にフェールオーバーされているかどうかを確認するには、Windows Server フェールオーバークラスター内の対応する可用性グループリソースを確認します。

説明

SQL Server と Windows Server フェールオーバークラスター間の通信が失われると、SQL Server エラーログでエラー 19407 が発生します。通常、修正アクションが発生します。別の Always On ノードへのフェールオーバーです。

リースは、SQL Server と Windows Server フェールオーバークラスター (WSFC) プロセス (特に RHS.EXE プロセス) の間で行われる時間ベースの通信メカニズムです。 2 つのプロセスは、他のプロセスが実行され、応答していることを確認するために、定期的に相互に通信します。この通信は Windows Event オブジェクトを使用して行われ WSFC の知識がなくても AG リソースのフェールオーバーが発生しないようにします。定義済みのリース期間に基づいて、いずれかのプロセスがリース通信に応答しない場合、リースタイムアウトが発生します。詳細については、「 Always On 可用性グループのリース、クラスター、正常性チェックのタイムアウトの概要とガイドラインを参照してください。「しくみ: SQL Server AlwaysOn のリースタイムアウト」も参照してください

原因

Windows イベントは軽量の同期オブジェクトであるため、それらに悪影響を与える外部要因の数は比較的少なくなります。リースタイムアウトにつながる可能性がある一般的な問題には、システム全体の問題が含まれます。リースの有効期限が切れ、再起動またはフェールオーバーが発生する可能性のある可能性の一覧を次に示します。

システムでの CPU 使用率が高い (100% に近い)。
メモリ不足の状態 - 仮想メモリが少ない、またはいずれかのプロセスがページアウトされています。
クォーラム損失が原因で WSFC がオフラインになる。クォーラム損失の問題をトラブルシューティングするには、「強制クォーラム (SQL Server) を使用したクォーラムの構成と管理およびWSFC ディザスターリカバリー」を参照してください。
VM の調整パフォーマンスに影響し、リースの有効期限が発生します。
大きなメモリダンプの生成中に SQL Server プロセスが応答しません。スタックダンプの生成の詳細については、ダンプ生成のを参照してください。スタックダンプの生成は、次のいくつかの理由で発生する可能性があります。
- 非提供スケジューラ
- ラッチタイムアウト
- デッドロックが発生したスケジューラ
- 未解決のデッドロック

ユーザーアクション

CPU 使用率の高い問題のトラブルシューティング

[タスクマネージャー] を開きます。
[パフォーマンス] タブに移動し、CPU の使用率が 100% に近いか、100% に近いかを確認します。
[ Processes タブに移動し、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(_Total)\Working Set" を "\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
    }
}
```
大量のメモリを消費している特定のアプリケーションを特定する場合は、それらのアプリケーションを別のシステムで停止または移動するか、メモリ使用量を制御することを検討してください。
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 秒)
すべてのレプリカの自動フェールオーバーを手動フェールオーバーに変更する
LeaseTimeout を 60,000 ミリ秒 (60 秒) に増やし、HealthCheckTimeout を 90,000 ミリ秒 (90 秒) に変更します。

詳細については、「 SQLDUMPER.EXE ツールを使用して SQL Server でダンプファイルを生成するを参照してください。

仮想マシン (VM) の構成でオーバープロビジョニングを確認する

仮想マシンを使用している場合は、CPU とメモリリソースをオーバープロビジョニングまたはオーバーコミットしていないことを確認します。 CPU またはメモリをオーバープロビジョニングすると、ゲスト OS がリソースを使い果たされ、前述の同じ問題 (CPU 使用率が高く、メモリが少ない) が表示される可能性があります。多くの場合、ゲスト OS 内でコンテンツを表示している場合、コンピューティングリソースが不足している理由を説明するのは困難です。これは、仮想マシン自体の外部で発生しているためです。リソースをオーバーコミットすると、処理が一時的に停止し、リースタイムアウトが発生する可能性があります。オーバーコミットに対処する方法の詳細については、「 ESX/ESXi 仮想マシンのパフォーマンスの問題 (2001003) と仮想マシンのオーバーコミット - メモリのオーバーコミットと VM 内での検出方法」を参照してください。

仮想マシン (VM) の移行またはバックアップを確認する

Hyper-V、VMware、およびその他の VM ソリューションは、ホストマシン間で VM を移動する機能を提供します (Hyper-V ライブマイグレーションと VMware vMotion)。ほとんどの場合、これらのテクノロジは、ほぼ瞬時の移行を提供します。ただし、ネットワークまたはホストマシンのボトルネックがある場合は、これらの移行が長期化する可能性があるため、VM が中断非運用状態になる可能性があります。これにより、SQL Server とクラスタープロセスの間でリースタイムアウトの有効期限が切れる可能性があります。リースタイムアウトの問題に対処する前に、まず VM 移行に関する問題を解決してください。

仮想マシンバックアップソリューションは、VM のダウンタイムを引き起こす可能性もあります。 VM のバックアップがホスト OS で実行されている場合、または長時間かかるホストコンピューターで同様のメンテナンスが行われると、リースタイムアウトの問題が発生する可能性があります。その理由は、クロックが刻まれている間、SQL Server プロセスとクラスタープロセスが中断された VM 上で相互に通信できないためです。リースタイムアウトの問題を調べる前に、まず VM バックアップまたはその他のメンテナンスによって発生する遅延に対処します。

次の方法で共有

MSSQLSERVER_19407

詳細

説明

原因

ユーザーアクション

CPU 使用率の高い問題のトラブルシューティング

メモリ不足の問題のトラブルシューティング

CPU、メモリ、ディスクのデータ収集をパフォーマンスモニターする

SQL Server またはクラスタープロセスの大きなメモリダンプを削減または回避する

仮想マシン (VM) の構成でオーバープロビジョニングを確認する

仮想マシン (VM) の移行またはバックアップを確認する

フィードバック

その他のリソース

次の方法で共有

MSSQLSERVER_19407

詳細

説明

原因

ユーザー アクション

CPU 使用率の高い問題のトラブルシューティング

メモリ不足の問題のトラブルシューティング

CPU、メモリ、ディスクのデータ収集をパフォーマンス モニターする

SQL Server またはクラスター プロセスの大きなメモリ ダンプを削減または回避する

仮想マシン (VM) の構成でオーバープロビジョニングを確認する

仮想マシン (VM) の移行またはバックアップを確認する

フィードバック

その他のリソース

ユーザーアクション

CPU、メモリ、ディスクのデータ収集をパフォーマンスモニターする

SQL Server またはクラスタープロセスの大きなメモリダンプを削減または回避する