Always On可用性グループのフェールオーバーのトラブルシューティング

この記事では、可用性グループがフェールオーバーされた理由を判断するのに役立つトラブルシューティング手順について説明します。

Always On正常性の問題またはフェールオーバーの症状と影響

Always Onでは、プライマリ レプリカ、基になるクラスター、およびシステムの正常性をホストする Microsoft SQL Server インスタンスの正常性を確保するために、さまざまなメカニズムを通じて堅牢な正常性監視を実装します。 運用環境のワークロードは、Windows クラスターまたはAlways On正常性の問題が特定されると一時的に中断されます。

正常性状態が検出されると、通常、次の一連のイベントが発生します。 このトラブルシューティング ツールでは、次のイベントを参照して正常性イベントについて説明します。

• 可用性グループのレプリカとデータベースは、プライマリ ロールから解決ロールに移行します。

• 可用性グループ データベースはオフラインに移行し、アクセスできなくなります。

• Windows クラスターは、可用性グループのクラスター化されたリソースを失敗としてマークします。

• Windows クラスターは、可用性グループの役割をオンラインに戻そうとします (元のフェールオーバー パートナー レプリカまたは自動フェールオーバー パートナー レプリカ上)。

• 可用性グループの役割は、Always Onと Windows クラスターの正常性の監視によって正常であることが検出された場合に、正常にオンラインになります。

成功した場合、可用性グループのレプリカとデータベースはプライマリ ロールに移行され、可用性グループ データベースはオンラインになり、アプリケーションからアクセスできます。

アプリケーションが可用性グループ データベースにアクセスできない

正常性状態が検出されると、可用性グループのレプリカとデータベースが解決ロールに移行し、可用性グループ データベースがオフラインになります。 レプリカがプライマリ ロール (元のレプリカ サーバーまたはフェールオーバー パートナー レプリカ サーバー上) でオンラインになると、レプリカとデータベースは再びオンラインに切り替わります。 レプリカとデータベースは解決中でオフラインですが、これらの可用性グループ データベースにアクセスしようとするアプリケーションは失敗し、"エラー 983" というメッセージが生成されます Unable to access availability database...。 失敗したログイン試行を記録するようにSQL Serverが構成されている場合、このエラーは Microsoft SQL Server エラー ログにも記録されます。

Logon Error: 983, Severity: 14, State: 1.

Logon Unable to access availability database '<databasename>' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

可用性グループがプライマリ ロールでオンラインに戻るまでの解決ロールに含まれる期間は、通常、数秒または 1 秒未満です。

可用性グループの正常性イベントまたはフェールオーバー Always On識別して診断する

1. Always Onの正常性の傾向を特定する

1 つのAlways On正常性イベントを調査することも、運用環境を断続的に中断している最近または進行中の正常性の問題の傾向が発生している可能性があります。 次の質問は、これらの正常性の問題に関連する可能性がある運用環境の最近の変更を絞り込んで関連付けるのに役立ちます。

• Always Onまたはクラスターの正常性イベントの傾向はいつ開始されましたか?
• 正常性イベントは特定の日に発生しますか?
• 正常性イベントは特定の時刻に発生しますか?
• 正常性イベントは月の特定の日または週に発生しますか?

傾向を検出した場合は、システム (仮想環境のホスト システム)、ETL バッチ、およびこれらの正常性イベントと関連付ける可能性があるその他のジョブで、スケジュールされたメンテナンスをチェックします。 システムが仮想マシンの場合は、障害発生時に発生した可能性のある変更についてホスト システムを調査します。

正常性の問題の時刻 (たとえば、ユーザーが最初にシステムにログオンしたとき、またはユーザーが昼食から戻った後など) に関連する可能性がある、ビジーなアドホック運用ワークロードを検討してください。

2. クラスター ログを確認する

Windows クラスター ログは、Always Onまたはクラスターの正常性イベントの種類と、イベントの原因となった検出された正常性状態を識別するために使用する最も包括的なログです。 クラスター ログを生成して開くには、次の手順に従います。

Windows PowerShellを使用して、正常性イベントの発生時にプライマリ レプリカをホストするクラスター ノードで Windows クラスター ログを生成します。 たとえば、SQL Server ベースのサーバー名として 'sql19agn1' を使用して、管理者特権の PowerShell ウィンドウで次のコマンドレットを実行します。

get-clusterlog -Node sql19agn1 -UseLocalTime     

3. クラスター ログで正常性イベントを見つける

Always Onでは、可用性グループの正常性を監視するために、いくつかの正常性監視メカニズムが使用されます。 Windows クラスター正常性イベント (Windows クラスターがクラスター ノード間の正常性の問題を検出する) に加えて、Always Onには 4 種類の正常性チェックがあります。

• SQL Server サービスが実行されていません
• SQL Server リースタイムアウト
• SQL Server正常性チェックタイムアウト
• SQL Server内部正常性の問題

これらのAlways On特定の正常性イベントのいずれかを見つけるには、[hadrag] Resource Alive result 0クラスター ログで 文字列 を検索します。 これらのイベントのいずれかが検出されると、この文字列はクラスター ログに保存されます。 例:

00001334.00002ef4::2019/06/24-18:24:36.153 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0.

ツールを使用すると、クラスター ログ内のすべての正常性イベントを見つけ、正常性の問題の概要レポートAlways On生成できます。 これは、時系列の傾向を特定し、特定の種類のAlways Onの正常性状態が繰り返し発生しているかどうかを判断するのに役立ちます。 次のスクリーンショットは、テキスト エディター (この場合は NotePad++) を使用して、文字列を含むクラスター ログ内のすべての行を検索する方法を [hadrag] Resource Alive result 0 示しています。

フェールオーバーをトリガーした正常性の問題の種類を特定する

プライマリ レプリカのクラスター ログで見つけた正常性の問題の種類を特定するには、次のいくつかのセクションで説明されている問題と比較します。

クラスター正常性イベント

Microsoft Windows クラスターは、クラスター内のメンバー サーバーの正常性を監視します。 正常性の問題が検出されると、クラスター メンバー サーバーがクラスターから削除される可能性があります。 また、クラスター リソース (削除されたクラスター メンバー サーバーでホストされている可用性グループ ロールを含む) は、自動フェールオーバー用に構成されている場合、可用性グループ フェールオーバー パートナー レプリカに移動されます。

クラスター正常性イベントの症状

クラスター ログのクラスター正常性イベントの例を次に示します。 これを見つけるには、可用性グループロールのLost quorumCluster service has terminated変更またはフェールオーバー中にどちらかが存在する可能性があるため、または を検索できます。

00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: Lost quorum (1)
00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: goingAway: 0, core.IsServiceShutdown: 0
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925)
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [NETFT] Cluster Service preterminate succeeded.
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925), executing OnStop
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM]: Shutting down, so unloading the cluster database.
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM] Shutting down, so unloading the cluster database (waitForLock: false).
000019cc.000019d0::2022/12/15-14:26:02.654 WARN [RHS] Cluster service has terminated. Cluster.Service.Running.Event got signaled.

このイベントを識別するもう 1 つの方法は、Windows システム イベント ログを検索することです。

Critical SQL19AGN1.CSSSQL 1135 Microsoft-Windows-FailoverClusterin Node Mgr NT AUTHORITY\SYSTEM Cluster node 'SQL19AGN2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Critical SQL19AGN1.CSSSQL 1177 Microsoft-Windows-FailoverClusterin Quorum Manager NT AUTHORITY\SYSTEM The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

クラスターの正常性イベントを診断する

Windows イベント ログ (イベント 1135 および 1177) のエラーは、ネットワーク接続がイベントの原因であることを示唆しています。 これは、クラスターの正常性の問題が検出される最も一般的な理由です。 次の例は、可用性グループのプライマリ レプリカをホストするこのサーバーと他のクラスター メンバー サーバーが通信できず、この問題によってクラスターからクラスター ノードが削除されたことを示しています。

00000fe4.00001edc::2022/12/14-22:44:36.870 INFO [NODE] Node 1: New join with n3: stage: 'Attempt Initial Connection' status (10060) reason: 'Failed to connect to remote endpoint <endpoint address>'
00000fe4.00001620::2022/12/15-14:26:02.050 INFO [IM] got event: Remote endpoint <endpoint address> unreachable from <endpoint address>
00000fe4.00001620::2022/12/15-14:26:02.050 WARN [NDP] All routes for route (virtual) local <local address> to remote <remote address> are down
00000fe4.0000179c::2022/12/15-14:26:02.053 WARN [NODE] Node 1: Connection to Node 2 is broken. Reason GracefulClose(1226)' because of 'channel to remote endpoint <endpoint address> is closed'

クラスター ログで、ノードへの接続エラーの証拠を検索できます。 が見つかったLost quorumクラスター ログ内の場所から、 などのFailed to connect to remote endpointunreachableis broken文字列を後方に検索します。

クラスターの正常性イベントを解決する

クラスターの正常性監視がホスト環境に適していることを確認します。 Microsoft Azure でホストSQL Server Always On可用性グループの詳細については、「Windows Server フェールオーバー クラスターの概要 - Azure VM 上のSQL Server」を参照してください。

必要な場合は、Microsoft Windows 高可用性サポートに問い合わせてサポート インシデントを開くことを検討してください。

SQL Server サービスが停止しています: Always On正常性イベント

Always On正常性監視では、可用性グループのプライマリ レプリカをホストするSQL Server サービスが実行されなくなったかどうかを検出できます。

SQL Server サービスのシャットダウンの症状

プロセス ID 0が返されたためQueryServiceStatusExに失敗したことを示す可用性グループ ロール 'ag' のクラスター ログ レポートのサンプルを次に示します。

00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] QueryServiceStatusEx returned a process id 0
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] SQL server service is not alive
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] Resource Alive result 0.
00001898.0000185c::2023/02/27-13:27:41.121 WARN [RHS] Resource ag IsAlive has indicated failure.

SQL Service シャットダウン イベントを診断して解決する

Windows システム イベント ログを確認し、予期しないSQL Serverシャットダウンがないかエラー ログをSQL Serverします。

システムのシャットダウンまたは管理シャットダウンによってSQL Serverがシャットダウンされた場合は、SQL Serverエラー ログに次のエントリが表示されます。

2023-03-10 09:38:46.73 spid9s SQL Serverは、Service Control Manager からの "停止" 要求に応答して終了しています。 これは情報メッセージのみです。 ユーザーの操作は必要ありません。

Windows システム イベント ログには、次のエラー エントリが表示されます。

情報 3/10/2023 9:41:06 AM Service Control Manager 7036 None SQL Server (MSSQLSERVER) サービスが停止状態に入った。

SQL Serverが予期せずシャットダウンした場合、Windows システム イベント ログに次のエラー エントリが表示されます。

エラー 3/10/2023 8:37:46 AM Service Control Manager 7034 None SQL Server (MSSQLSERVER) サービスが予期せず終了しました。 この 1 回が完了しました。

SQL Serverエラー ログの末尾に手がかりがないか確認します。 エラー ログが突然終了した場合、これは強制的にシャットダウンされたことを意味します。 たとえば、タスク マネージャーを使用してSQL Serverが終了した場合、SQL Server エラー レポートでは、プロセスのシャットダウンの原因となった内部の問題に関する情報は表示されません。

SQL Server内部正常性の問題によってSQL Serverが予期せず終了した場合、SQL エラー ログの最後に致命的な例外 (ダンプ ファイル診断の生成を含む) が発生する可能性があります。 手がかりを確認し、必要なアクションを実行します。 ダンプ ファイルが見つかる場合は、Microsoft SQL Server サポートに問い合わせて開き、詳細な調査のためにSQL Serverエラー ログとダンプ ファイルの内容を提供することを検討してください。

リース タイムアウト: Always On正常性イベント

Always Onでは、"リース" メカニズムを使用して、SQL Serverがインストールされているコンピューターの正常性を監視します。 既定のリース タイムアウトは 20 秒です。

リース タイムアウト イベントAlways Onの症状

クラスター ログからのAlways Onリースタイムアウトの出力例を次に示します。 これらの文字列を検索して、クラスター ログ内のリース タイムアウトを見つけることができます。

00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Availability Group lease is no longer valid 
00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0. 
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:35:57.0, 98.068572, 509227008.000000, 0.000395, 0.000350 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:7.0, 12.314941, 451817472.000000, 0.000278, 0.000266 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:17.0, 17.270742, 416096256.000000, 0.000376, 0.000292 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:27.0, 38.399895, 416301056.000000, 0.000446, 0.000304 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:37.0, 100.000000, 417517568.000000, 0.001292, 0.000666

リースタイムアウトの詳細については、可用性グループのリース、クラスター、正常性チェックタイムアウトの仕組みとガイドラインの「リース メカニズム」セクションAlways On参照してください。

リース タイムアウト イベントAlways On診断して解決する

リースタイムアウトをトリガーする可能性がある 2 つのメインの問題があります。

• SQL Server ダンプ ファイルの診断: アクセス違反、アサーション、スケジューラのデッドロックなど、特定の内部正常性イベントをSQL Serverが検出すると、SQL Server \LOG フォルダーに診断ダンプ ファイル (.mdmp) が生成されます。

• システム全体のパフォーマンスの問題: リースタイムアウトは、必ずしもSQL Server正常性の問題を示すわけではありません。 代わりに、システム全体の正常性の問題を示し、SQL Server ベースのサーバーの正常性にも影響を与える可能性があります。 トラブルシューティングの詳細については、「 MSSQLSERVER_19407」を参照してください。

1. ダンプ ファイルの診断SQL Server

SQL Serverは、アクセス違反、アサーション、デッドロックされたスケジューラなどの内部正常性の問題を検出する可能性があります。 この状況では、診断のために、SQL Server プロセスの SQL Server \LOG フォルダーにミニ ダンプ ファイル (.mdmp) が生成されます。 ミニ ダンプ ファイルがディスクに書き込まれている間、SQL Server プロセスは数秒間フリーズします。 この間、SQL Server プロセス内のすべてのスレッドがフリーズ状態になります。 これには、正常性監視によって監視されるリース スレッドAlways On含まれます。 そのため、Always Onはリースタイムアウトを検出する可能性があります。

**Dump thread - spid = 0, EC = 0x0000000000000000
***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
* *******************************************************************************
*
* BEGIN STACK DUMP:
*   11/02/14 21:21:10 spid 1920
*
* Deadlocked Schedulers
*
* *******************************************************************************
* -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000002BA
Error: 19407, Severity: 16, State: 1.
The lease between availability group 'ag' and the Windows Server Failover Cluster has expired. A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. To determine whether the availability group is failing over correctly, check the corresponding availability group resource in the Windows Server Failover Cluster.

この問題を解決するには、ダンプ ファイルの診断で根本原因を調査する必要があります。 詳細な調査のために、microsoft SQL Server サポートに問い合わせてSQL Serverエラー ログとダンプ ファイルの内容を提供することを検討してください。

2. CPU 使用率が高い、またはその他のシステム パフォーマンスの問題

リースタイムアウトは、SQL Serverを含むシステム全体に影響を与えるパフォーマンスの問題を示します。 システムの問題を診断するには、正常性診断Always On、クラスター ログにパフォーマンス モニター データを報告し、リースのタイムアウト イベントを含めます。 パフォーマンス データは、リース タイムアウト イベントまでの約 50 秒に及び、CPU 使用率、空きメモリ、ディスク待機時間について報告します。

クラスター ログのリース タイムアウトを示す、報告されたパフォーマンス データの例を次に示します。 このサンプル出力では、リースタイムアウトに関連する可能性がある全体的な CPU 使用率が高くなります。

00000f90.000015c0::2020/08/07-14:16:41.378 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00000f90.000015c0::2020/08/07-14:16:41.382 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:20.0, 83.266073, 31700828160.000000, 0.018094, 0.015752
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:30.0, 93.653224, 31697063936.000000, 0.038590, 0.026897
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:40.0, 94.270691, 31696265216.000000, 0.166000, 0.038962
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:50.0, 90.272016, 31695409152.000000, 0.215141, 0.106084
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:16:1.0, 99.991336, 31695892480.000000, 0.046983, 0.035440

リースタイムアウト時にパフォーマンス データの CPU 使用率が高い、メモリの状態が少ない、またはディスクの待機時間が長い場合は、プライマリ レプリカで 1 日のデータパフォーマンス モニター収集を開始して、これらの現象を調査します。 パフォーマンス モニター データを長期間にわたってキャプチャすることで、これらのリソースのベースライン値とピーク値をより適切に特定し、リースタイムアウトが発生したときにこれらのリソースの変更を監視できます。 このデータを収集するときに、リソースの問題や正常性イベントの時刻に関連する特定のスケジュールされたワークロードまたはアドホック ワークロードがSQL Serverに存在するかどうかを検討します。

また、次のような同じシステム リソースの使用状況を報告するカウンターもキャプチャする必要があります。

• Processor Information::% Processor Time
• Memory::Available MBytes
• Logical Disk::Avg. Disk sec/Read
• Logical Disk::Avg. Disk sec/Write
• Logical Disk::Avg. Disk Read Queue Length
• Logical Disk::Avg. Disk Write Queue Length
• MSSQLServer:SQL Statistics::Batch Requests/sec

正常性チェックタイムアウト: Always On正常性イベント

可用性グループ レプリカがプライマリ ロールに移行すると、正常性監視Always On、SQL Server インスタンスへのローカル ODBC 接続が確立されます。 Always Onが接続および監視されている間、可用性グループの正常性 SQL Serverチェックタイムアウト (既定値は 30 秒) に設定されている期間内に ODBC 接続経由で応答しない場合は、正常性チェックタイムアウト イベントがトリガーされます。 この状況では、可用性グループはプライマリ ロールから解決中ロールに移行し、フェールオーバーを開始します (これを行うために構成されている場合)。

正常性チェックタイムアウトの詳細については、「可用性グループのリース、クラスター、正常性チェックタイムアウトの仕組みとガイドライン」の「正常性チェックタイムアウト操作」セクションAlways On参照してください。

クラスター ログで報告されたAlways On正常性チェックタイムアウトを次に示します。

0000211c.00002d70::2021/02/24-02:50:01.890 WARN [RES] SQL Server Availability Group: [hadrag] Failed to retrieve data column. Return code -1
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Resource Alive result 0.
0000211c.00002594::2021/02/24-02:50:02.453 WARN [RHS] Resource AG IsAlive has indicated failure.
00001278.00002ed8::2021/02/24-02:50:02.453 INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'AG', gen(0) result 1/0.

正常性Always Onタイムアウト イベントチェック診断して解決する

次のセクションでは、検出され、報告されるAlways On正常性チェックタイムアウトに関連する "パン粉" イベントのSQL Server ログを確認するのに役立ちます。 ここで確認するログには、クラスター ログ (正常性チェックタイムアウトが確認されている場所)system_health、拡張イベント ログとSQL Serverエラー ログ (両方とも SQL Server \LOG フォルダーにあります)、および Windows システム イベント ログが含まれます。 これらのログとその他のログを使用して、正常性チェックタイムアウトの原因の範囲を指定するのに役立つ可能性がある関連イベントを検索します。

1. 生成されていないスケジューラ イベントを確認する

Always On正常性チェックタイムアウトは、多くの場合、SQL Serverの "非生成" イベントによって発生します。 SQL Serverは、スレッドがスケジューラに生成されていないことを検出すると、生成されないスケジューラ イベントが発生したことを報告します。 CPU 時間を受け取っていない同じスケジューラに他のタスクが表示される場合、これは非生成スケジューラの主な兆候です。 この動作により、これらのタスクの実行が遅れ、CPU 時間の特定のスケジューラに割り当てられる "飢えた" ワークロードが発生する可能性があります。

生成されていないスケジューラ イベントをチェックするには、次の手順に従います。

1. SQL Serversystem_healthの拡張イベント ログを調べて、Always On正常性チェックタイムアウト イベントの前後に、何らかの非生成スケジューラ イベントが報告されたかどうかを確認します。 見つかる可能性のある非生成イベントには、次のものが含まれます。

   • scheduler_monitor_non_yielding_ring_buffer_recorded
   • scheduler_monitor_non_yielding_iocp_ring_buffer_recorded
   • scheduler_monitor_stalled_dispatcher_ring_buffer_recorded
   • scheduler_monitor_non_yielding_rm_ring_buffer_recorded

2. プライマリ レプリカのSQL Serverシステム正常性拡張イベント ログを、正常性が疑われるチェックタイムアウトの時刻まで開きます。

3. SQL Server Management Studio (SSMS) で、[ファイルを>開く] に移動し、[拡張イベント ファイルのマージ] を選択します。

4. [追加] ボタンを選択します。

5. [ファイルを開く] ダイアログ ボックスで、SQL Server \LOG ディレクトリ内のファイルに移動します。

6. Control キーを押しながら、名前が で始まるファイルをsystem_health_xxx.xel選択します。

7. [ OK を開く]>を選択します。

8. 結果をフィルター処理します。 [名前] 列の下にあるイベントを右クリックし、[この値でフィルター処理] を選択します。

   

9. 次のスクリーンショットに示すように、 名前 列の値に が含まれる yield行を並べ替えるフィルターを定義します。 これにより、ログに記録されている可能性がある、すべての種類の非生成イベントが system_health 返されます。

   

10. タイムスタンプを比較して、正常性チェックタイムアウト時に生成されていないイベントがあったかどうかを確認します。クラスター ログで報告される正常性チェックタイムアウトを次に示します。

    0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1: [hadrag] Resource Alive result 0.
    

    正常性チェックタイムアウト時に発生した非生成イベントが発生していることがわかります。

    

非生成イベントが検出された場合は、非生成イベントの原因をチェックします。 SQL Server サポート チームに問い合わせて、生成されていないイベントを調査することを検討してください。

2. SQL Serverエラー ログを確認する

SQL Serverエラー ログで、正常性チェックタイムアウト時のイベントの関連付けについて確認します。これらのイベントは、正常性チェックタイムアウトの根本原因をスコープする追加の手順を提案する "パン粉" を提供する場合があります。

たとえば、次のログ エントリは、クラスター ログで正常性チェックタイムアウトが発生したことを示しています。

0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Resource Alive result 0.

SQL Server エラー ログで、正常性チェックタイムアウトから数秒以内に、重大な I/O 待機時間が検出されたことを報告SQL Server。

2021-02-23 20:49:54.64 spid12s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\agdb_log.ldf] in database id 12. The OS file handle is 0x0000000000001594. The offset of the latest long I/O is: 0x000030435b0000. The duration of the long I/O is: 26728 ms.

システム イベント ログで、正常性チェックタイムアウト イベントに関連する可能性のあるシステムの手掛かりを確認します。 Windows システム イベント ログを確認すると、同じ正常性チェックタイムアウトに対して同時に報告される I/O の問題が見つかる場合があります。

02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"Reset to device, \Device\<device ID>, was issued."
02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"The IO operation at logical block address <block address> for Disk 6 (PDO name: \Device\<device ID>) was retried."

SQL Server正常性: Always On正常性イベント

Always Onは、さまざまな種類のSQL Server正常性イベントを監視します。 可用性グループのプライマリ レプリカをホストしていますが、SQL Serverは、さまざまなコンポーネントを使用してSQL Server正常性に関するレポートを継続的に実行sp_server_diagnosticsします。 正常性の問題が検出されると、sp_server_diagnosticsその特定のコンポーネントのエラーが報告され、その結果がAlways On正常性検出プロセスに送信されます。 エラーが報告されると、可用性グループロールは失敗した状態と、可用性グループがこれを行うために構成されている場合に可能なフェールオーバーを示します。

Always On SQL Server正常性イベントの症状

クラスター ログで報告されるsp_server_diagnosticsSQL Server正常性の問題の例を次に示します。 SQL Serverは、システム コンポーネントの "エラー" 状態を報告して正常性監視をAlways Onし、"contoso-ag" 可用性グループが失敗状態に移行します。

INFO [RES] SQL Server Availability Group: [hadrag] SQL Server component 'system' health state has been changed from 'warning' to 'error' at 2019-06-20 15:05:52.330
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Resource Alive result 0.
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
WARN [RHS] Resource contoso-ag IsAlive has indicated failure.
INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'contoso-ag', gen(0) result 1/0.

SQL Server正常性イベントを診断して解決する

SQL Server正常性によって報告される正常性の問題の種類は、根本原因分析の方向を決定する必要があります。

既定では、可用性グループをデプロイすると、 FAILURE_CONDITION_LEVEL は 3 として設定されます。 これにより、一部の正常性プロファイルの監視がアクティブになりますが、一部のSQL Server正常性プロファイルではありません。 既定のレベルでは、Always Onは、SQL Serverがダンプ ファイル、書き込みアクセス違反、または孤立したスピンロックを生成しすぎると、正常性イベントをトリガーします。 可用性グループをレベル 4 または 5 に設定すると、監視されるSQL Server正常性の問題の種類が拡張されます。 SQL Server正常性Always On モニターの詳細については、「可用性グループの柔軟な自動フェールオーバー ポリシーの構成 - SQL Server Always On」を参照してください。

特定の正常性の問題Always On特定するには、次の手順に従います。

1. プライマリ レプリカでSQL Serverクラスター診断拡張イベント ログを開き、正常性イベントが発生したと思われる時点SQL Server開きます。

2. SSMS で、[ ファイルを>開く] に移動し、[ 拡張イベント ファイルのマージ] を選択します。

3. [追加] を選択します。

4. [ファイルを開く] ダイアログ ボックスで、SQL Server \LOG ディレクトリ内のファイルに移動します。

5. Control キーを押し、名前が一致<servername>_<instance>_SQLDIAG_xxx.xelするファイルを選択し、[OK を開く>]を選択します。

   

   次のスクリーンショットに示すように、SSMS に拡張イベントを含む新しいタブ付きウィンドウが表示されます。

6. SQL Server正常性の問題を調査するには、値state_descerrorが である をcomponent_health_result見つけます。 正常性監視にエラーを報告Always Onシステム コンポーネント イベントの例を次に示します。

   

7. 下のウィンドウで データ 列をダブルクリックします。 これにより、新しい SSMS ウィンドウ ウィンドウで詳細なコンポーネント データが開き、確認が行われます。 システム コンポーネント データの外観を次に示します。

   

   "totalDumprequests=186" データは、このSQL Serverで生成されたダンプ ファイル診断イベントが多すぎることを示していることに注意してください。 これは、システム コンポーネントがエラー状態を報告した理由です。 正常性監視Always Onこのエラー状態を受け取ると、可用性グループの正常性イベントがトリガーされます。 また、システム コンポーネント データで提供されるデータから、書き込みアクセス違反や孤立スピンロックが検出されていないことも確認できます。

   必要な場合は、SQL Server サポートに問い合わせてサポート インシデントを開き、これらの内部SQL Serverの健康問題の根本原因を見つける際にさらに支援を受けてください。