SQL Server 2005で一時ログのサイズを制限しても大丈夫ですか？
私が調査している問題があります。それにより、tempdbログファイルが賢明と思われるものに比例して大きくなります。今朝はデータファイルの10倍以上のサイズでした。ただし、データベースは引き続き正常に機能し、一時ログのサイズの唯一の制限は、データベースが存在するディスクのサイズであるようです。
それでは、私の質問は、templogのサイズを制限しても安全でしょうか。SQLサーバー内で実行する必要のある作業にとって重要であるため、tempdbのサイズを制限するべきではないと聞いています。しかし、ログファイルがディスクで許可されているサイズまで大きくなるという事実は、何も壊さずにログファイルを制限できることを示唆しています。これは本当ですか？もしそうなら、下限（つまり、データファイルの合計サイズ）はありますか？以下に制限するべきではありませんか？
ところで、これはログの増大の問題に対する解決策ではなく、調査中ですが、すぐには解決されない可能性があることを認識しています。
乾杯、
ログのサイズを制限することによって行うことは、ログを成長させているものは何でもが制限に達したときに失敗を引き起こすことだけです。 （エラーが発生し、おそらくトランザクションがロールバックされます）。
実際、ログが非常に大きくなっているものを確認するための便利な方法かもしれません。 :) さらに良い方法は、Perfmonを使用してSQL：Database：Log Used（kb）カウンターを監視し、whenが増加していることを確認し、それをサーバー上のその他のアクティビティ。
マイクロソフトにPSSコールを提起し、問題を詳細に調査した後、次の考えられる原因と解決策にゾーニングした後、同様の問題が発生しました。
原因：
症状の考えられる原因は、ユーザーデータベースが配置されているディスク/ lunに重大なI/O応答の問題があることが原因です。これにより、ユーザーデータベースの自動チェックポイントが完了するまでに非常に長い時間がかかります。
現在、tempdbのチェックポイントは、tempdbログが70％いっぱいになり、ユーザーデータベースのチェックポイントよりも優先度が低い場合にのみ発生します。したがって、ユーザーデータベースの自動チェックポイントが発行されて完了しようとすると、tempdbの使用量が多いため、tempdbログファイルがすぐにいっぱいになります。ログ使用率が70％になると、tempdbチェックポイントが発生しますが、ユーザーデータベースチェックポイントの後ろにキューに入れられます。
ユーザーデータベースのチェックポイントが完了するまでに、tempdbログファイルがいっぱいになり続けます。自動拡張が設定されている場合、より多くのスペースが必要になるとログファイルが大きくなります。これが、ログファイルが増え続ける理由です。
要約すると、説明する症状の最も可能性のある根本原因は、ユーザーおよび/またはtempdbデータベース/ログファイルのディスク/ lunからのI/O応答が不十分なためです。
解決策：
I/Oサブシステムを整理する際に、tempdbログファイルが75％いっぱいになったときに発生するアラートを設定し、それに応じて手動の「チェックポイント」（自動システムよりも優先される）を強制するジョブを実行することで、この問題を回避しました。チェックポイント）、tempdbログをクリアして、無期限に自動拡張されないようにします。他の不測の事態に備えて、ログファイルを自動拡張のままにしておくことをお勧めします。
お役に立てれば。