他のサーバーが1つあるAO高可用性グループでSQL Server 2012 (11.0.6540.0)
を実行しています。
tempDBの使用量は通常約819MB(2週間前からの平均で1週間)ですが、フェイルオーバーとパッチサイクルを行ったため、tempDBは徐々に増加し始めました(現時点ではDDLの変更は行われていません)。テストのフェールオーバーを実行し、tempDBをジョイントから外しましたSAN両方のマシンがアクセスできるドライブ、両方をダウンさせることができる1つのハードウェアは必要ありません。プライマリとセカンダリのレプリカ)。
最新のフェイルオーバーとインスタンスの再起動(tempDBを移動するため)では、tempDBの使用量が6348MBに急増し、その使用量は徐々に増加しています。
成長はすべて、次のものを使用して確認できる内部オブジェクトにあります。
SELECT top 5 session_id, request_id,
SUM(internal_objects_alloc_page_count) AS request_internal_objects_alloc_page_count
FROM sys.dm_db_task_space_usage
GROUP BY session_id, request_id
ORDER BY request_internal_objects_alloc_page_count DESC
それを見ると、すべてService Packに関連するspid 35と32から実行されています。
私は周りを見てきたが、これはWITH CLEANUP
会話の終わりに、Wordのクリーンアップはコメントにしか表示されないので、これは問題ではないと確信しています。
インスタンスが復旧してプライマリノードを引き継いだとき、サービスブローカーは機能していなかったため、すべてのキューを無効にしてから有効にするサイクルに切り替える必要がありました(1年前に1回これを実行する必要がありましたが、実行しませんでした)この問題を参照してください)。
TempDBの使用状況は、過去4日間の現在の状態です。今朝のドロップオフは、インスタンスの再起動とフェイルオーバーです。
これを制御下に戻すために、私が何が欠けているかを誰かが知っていますか?.
TLDR;会話が完全に開いたままになっていることを確認します。
私たちのシステムでは会話を再利用し、使用可能なこれらの会話を保持するための専用のテーブルを持っていますが、開発チームは、私が不在のときに何年も前に私の知識なしに新しいService Brokerをセットアップし、これらの会話ポイントを設定していませんでした。アラートにしきい値を設定しないでください。
新しいシステムがオンになったとき、会話は開かれているが適切に閉じられておらず、プールに何もないため、新しい会話を作成しているだけです(1つのサービスブローカーで710万の会話に達しました)。
修正するための手順は、そのService Brokerに必要な20個の会話ハンドラーを作成して記録し、それらをテーブルに記録することでした。これにより、tempDBの増加が止まり、DBがダウンするリスクがなくなりました。
その後、未使用の会話をすべて閉じるという長いプロセスが始まりました
select
se.[conversation_handle]
from
sys.conversation_endpoints se with (nolock)
left outer join [queue].[maintained_Conversations] qh with (nolock) on qh.[conversation_handle] = se.[conversation_handle]
where
qh.service_name is not null
and se.far_service = @service
それらの値を介してすべてのIDカーソルのリストを提供し、それらのそれぞれに対して単にEND CONVERSATION @id;
を実行します。
プロセスが完了すると、一時DBスペースは解放されます(閉じると、そのようにはなりません。それらの作成/終了に取り組んでいないときは、大きなチャンクで行われているようです(これは保証できません)それがどのように機能するか、中間プロセスを停止してtempDBがスペースを取り戻した後に私が観察したものだけです)