SQLエラーログ定数FlushCacheメッセージ
SQL 2017 Always on可用性グループ（BAG）の一部であるサーバーこれらのメッセージの増加に気づきました。これらは2012年以降の標準としてログに表示されるメッセージ（2012年より前のトレースフラグ）であると理解していますが、過去2日間は数分ごとに表示され、これらの時間に実行中のバックアップやメンテナンスジョブはありません。
サーバーは、読み取り不可能なセカンダリフェイルオーバーパートナーとして機能しており、プライマリサーバーは同じ動作を示していません。
09/04/2020 10：52：24、spid82s、Unknown、FlushCache：db 7：0の81090ミリ秒で1881の書き込みで2303 bufsをクリーンアップ（11の新しいダーティbufsを回避）09/04/2020 10：52：07、 spid52s、不明、最後のターゲット未処理：2 avgWriteLatency 86 09/04/2020 10：52：07、spid52s、不明、1秒あたりの平均書き込み数：17.70書き込み/秒平均スループット：0.19MB /秒I / O飽和：13073コンテキストスイッチ15434
また、ディスクの問題に関する警告がシステムエラーログにあります。この数秒後、FlushCacheメッセージが増加してから可用性グループがフェイルオーバーしました。
誰かが同様のことを経験したり、アドバイスがあったりしましたが、私のシステム管理者はSANとVMwareの資産も調べています。
これらは自動成長活動によって引き起こされる可能性があると突然考えましたか？
回答
間接チェックポイントに切り替えます（通常、少なくともユーザーデータベースの場合、回復間隔時間を60秒に設定します）。
私はこの問題についてこことここに書いたので、変更を加える前にそれらの投稿を完全に読む必要がありますが、それは非常に簡単な私見です。
私たちの環境への影響は劇的かつ即時であり、変更が原因であることを証明するのは簡単でした。症状のあるすべてのデータベースは、30〜60秒のチェックポイントとこれらのメッセージでいっぱいのエラーログから1秒未満のチェックポイントになり、エラーログエントリはなくなりました。
ワークロードの軽減手法もおそらくあります。たとえば、Itzik Ben-Ganによるこの投稿を参照してください。ただし、チェックポイントをより効率的にすることは、より迅速で簡単な方法です。ただし、ストレージとVMの担当者はオフフックではありません。対処する必要のあるディスクの問題は間違いなくあります（ただし、これらのFlushCacheメッセージがフェイルオーバーの根本原因であることに同意しません。おそらく別の犠牲者/症状である可能性があります）。
最近ファームウェアの更新があるかどうか、またはストレージサブシステムに新しいファームウェアの更新が必要かどうかをストレージ管理者に確認してください。SQL環境でこのメッセージを何度も見ましたが、確認できるのはストレージレイヤーの構成です（これが一般的な原因です）。また、perfmonを使用してディスクパフォーマンスを監視することも1つあります。ディスクカウンタは、あなたがに焦点を当てる必要があります：avg disk sec/Read、avg disk sec/Write、avg disk sec/Transfer。
以下のリンクを確認できます。
- 仕組み：FlushCacheメッセージはいつSQL Serverエラーログに追加されますか？
- https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-when-is-the-flushcache-message-added-to-sql-server/ba-p/317038
ストレージレイヤーと言うときは、次のことを確認してください：HBA / CNA、ファイバーケーブル、FCスイッチ、ポート、ストレージコントローラー、ソフトウェア（MPIOドライバー）-すべての構成
最後に、イベントログの警告/エラーメッセージを常に確認して調査することを強くお勧めします。この種のメッセージは将来的に長期的な影響を与えるため、通過させないでください。