データベースレベルのヘルスチェックで、ディスクの喪失時にフェイルオーバーがトリガーされなかった
2016 SQL Enterprise SP2 CU7エディションで新しいデータベースレベル検出オプションをテストしていますが、期待どおりに動作していないようです。 2ノードのセットアップ、同期コミット、両方のノードでの自動フェイルオーバーがあります。データベースレベルのヘルス検出オプションがオンになっています。プライマリノードで、AGにあるDBのデータファイルの1つを含むドライブをオフラインにしました。欠落しているディスクから読み取ったテーブルからselect *を実行したところ、予想される823エラーが発生し、エラーログに記録されました。数回実行すると、エラーログに823が複数回記録されました。
これが発生したときに想定されていたように、可用性グループはフェイルオーバーしませんでした。フェイルオーバーが発生するかどうかを確認するために約3分間待機しましたが、フェイルオーバーは発生しませんでした。 DBレベルのヘルスチェックルーチンが実行されるように設定されている頻度を確認するにはどうすればよいですか？この記事によると、これは4つの連続した実行で問題を表示する必要があることを理解しています： 拡張データベースレベルのフェイルオーバー
AGでヘルスチェックのタイムアウト値を確認したところ、30秒でした。
サーバーの障害状態レベルも確認しましたが、これはOn CriticalServerErrorsに設定されていますが、理解しているように、この設定はデータベースレベルのヘルスチェックとは完全に独立しており、どちらかが独自にフェイルオーバーをトリガーできるはずです。 。これは正しいです？
これを防ぐことができると私が考えることができる唯一のことは、WSFCマネージャーでの保留中のタイムアウトです。これには、クラスターリソースをオフラインにする前の3分の値があります。
なぜこれがフェイルオーバーしなかったのか、他にどこを探したらいいのでしょうか？
プライマリノードで、AGにあるDBのデータファイルの1つを含むドライブをオフラインにしました。不足しているディスクから読み取るテーブルからselect *を実行しました[...]
あなたが2016にいるので、データベースレベルのヘルスチェックは、データベースがオンラインであること（セカンダリファイルをオフラインにしても変更されない）、およびトランザクションログに書き込むことができることを確認しています。これらの両方が真であるため、テストに合格します。これが2016年の仕組みです。
なぜこれがフェイルオーバーしないのか、他にどこを探したらいいのでしょうか？
はい、上記を参照してください。これは、2017年により多く含まれるように変更されました。