再起動後に読み取り可能なセカンダリで奇妙なブロッキング
同期（この場合はSQL2）と非同期セカンダリレプリカの3つのレプリカを持つSQL Server 2014可用性グループを実行しています。また、同期セカンダリレプリカへの読み取り専用ルーティングを構成しました。
昨夜、SQL2はWindowsの自動更新インストールから再起動しました。サーバーがオンラインに戻り、SQL Serverサービスが開始（遅延開始）し、データベースが回復しました。しばらくすると、イベントビューアはデータベースの整合性チェックが成功し、データベースを使用できるようになったことを示しました。
データベースは、SQL Management Studioで同期状態を示しました。 AGの状態は正常でしたが、クエリがデータベースから結果を取得していませんでした。
クエリは待機タイプによってブロックされました：HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING。
時々、待機タイプが「lck_m_s」待機タイプに変更され、DB起動コマンドを実行するプロセスであるpidによってブロックされました。これはSQL Server Enterpriseに付属する高速復旧オプションに関係していることはわかっていますが、単純な選択が永久にブロックされた理由がわかりません。
主な質問は次のとおりです。SQLServerは、AGデータベースが正常であることをどのように示すことができますか？この問題を認識していますか？
これを修正するために、AGからセカンダリを削除し、データベースをAGに再度参加させ、すべてが再び機能するようになりました。
PFEブログのこの投稿で説明されている動作を経験したようです。
基本的に、セカンダリが読み取り可能になったときに、プライマリで長時間トランザクションが発生したため、スナップショット関連の行バージョンが利用可能になるまで、クエリはセカンダリでブロックされます。データベースの削除と再追加が、長時間実行されているトランザクションが最終的に完了するのと偶然だったと思います。
そのため、このブログ投稿で説明されているように、この動作は仕様によるものです。
ただし、長期実行トランザクションがなかった場合、これはバグである可能性があります。他の人がこの問題を抱えていることを示すコメントがそのブログにあります：
OSのパッチ適用後にセカンダリSQL Serverを再起動した後、問題に直面しています。再起動する前に、プライマリで開いているトランザクションを確認しないでください。 AGにはこの問題のある2つのデータベースがあります。そして、私たちは15時間以上待っていましたが、それでも読み取り可能なレプリカはそれらのデータベースの選択クエリを処理できません。
この動作を繰り返すことができる場合は、 フィードバックサイト で報告するか、サポート契約を結んでいる場合はMicrosoftサポートに連絡することをお勧めします。