templog.ldfが巨大（45GB）ですが、どうすればよいですか？

SQL 2005をインストールしましたが、templog.ldfファイルが増え続けて、ドライブの空き領域がすべて消費されています。場合によっては数MBの空き容量で停止することもありますが、さらに進む場合もあります。これはcドライブであるため、この動作は、これまでに見られている他のいくつかの問題に関係していると思います。

私の質問は、どうすればいいですか。ログを別のドライブに移動できますが、そこで同じことは行われないだけだと思います。この動作は私が変更できる何かの結果である可能性が高く、tempdbログが到達するための異常なサイズは45 GBであると想定しています。コードでは多くの一時テーブルとテーブル値関数を使用しているため、tempdbを使用するための十分な範囲があります。tempdbデータベースの増加は理解できますが、templogの増加の理由は理解できません。

これまでのところ、DBCC OPENTRAN（ 'tempdb'）を実行して、古いトランザクションが滞っていないかどうかを確認しましたが、滞っていません。tempdbを縮小する方法について読み、これを数回実行しましたが、これを最初に停止するために何ができるか、なぜそれがそれほど大きく成長しているのかについての詳細を本当に考えていますそもそも。

==編集==

1） tempdbは単純な復旧モデルを使用しています

2） templogの増加は、いくつかのスケジュールされたクエリを実行している午前中の数時間にわたって発生します。この間、ファイルのサイズは着実に増加します。同時に実行する同時レポートの数を制御します。同時レポートの数を増やすと、ログの増加率が上がります。

レポートクエリを確認します。DISTINCTを含むものはありますか？それらのいずれかにデカルト結合がありますか？

レポートクエリのいずれかが、結合のメンバーとしてリンクサーバーにアクセスしますか？その場合、tempdbのログとデータベースが大きくなる可能性があります。

レポートが午前中に実行されているときに、それらのいずれかがクラッシュしますか？

MicrosoftとのPSSコールを発信し、問題の詳細な調査を行った後、次の考えられる原因と解決策に分類して、同様の問題が発生しました。

原因：

症状の考えられる原因は、ユーザーデータベースが配置されているディスク/ lunに重大なI / O応答の問題があることが原因です。これにより、ユーザーデータベースの自動チェックポイントが完了するまでに非常に長い時間がかかります。

現在、tempdbのチェックポイントは、tempdbログが70％いっぱいになったときにのみ発生し、ユーザーデータベースのチェックポイントよりも優先度が低くなっています。したがって、tempdbの使用量が多いために、ユーザーデータベースで自動チェックポイントが発行されて完了しようとすると、tempdbログファイルがすぐにいっぱいになるため、事実上、ログ使用率が70％の場合、tempdbチェックポイントが発生しますが、ユーザーデータベースチェックポイントの背後でキューに入れられます。

ユーザーデータベースのチェックポイントが終了するまでにtempdbのログファイルがいっぱいになり、自動拡張が設定されている場合、より多くの領域が必要になるとログファイルが大きくなります。これがログファイルが増加し続ける理由です。

要約すると、あなたが説明する症状の最も可能性のある根本的な原因は、ユーザーおよび/またはtempdbデータベース/ログファイルのディスク/ lunからの不十分なI / O応答によるものです。

解決：

tempdbログファイルが75％いっぱいになったときに発生するアラートを設定し、それに応じて手動の「チェックポイント」を強制するジョブを実行することにより、I / Oサブシステムを整理しながら問題を回避しました（自動システムよりも優先されます）チェックポイント）、tempdbログを消去して、無期限に自動成長するのを防ぎます。他の不測の事態に備えて、ログファイルを自動拡張のままにしておくことをお勧めします。また、修正を適用した後、tempdbログファイルのサイズを環境に応じて意味のあるものに減らすことを検討することを強くお勧めします。

お役に立てれば。

temp dbで設定されている復旧モデルは何ですか？Simpleに設定されていない場合は、Simpleに設定します。これはそれが成長しないようにする必要があります。それがすでにSimpleに設定されている場合は、対処する必要のある根本的な問題があり、ファイルを縮小しようとしても、根本的な原因ではなく、問題の症状が処理されるだけです。

私はこの数時間を読んで、これについてメモをとっています

http://technet.microsoft.com/en-gb/library/cc966545.aspx

そこには多くの詳細と問題のトラブルシューティングの提案があります。tempdbが拡大して止まらない場合を除いて、tempdbは必要なスペースを占有しているだけで、最初はそのサイズに設定されているはずです。tempdbに必要なスペースの見積もりと、tempdbでスペースを占有している可能性があるものを追跡するセクションがあります。この結果、私が最初に行うのは、tempdbをより大きなドライブに移動し、そこから何が起こるかを確認することです。

ログを使用する機能を示す「tempdbロギングに必要なスペース」というタイトルのセクションがあり、tempdbを使用する機能のスーパーセットを詳しく説明する以前のセクションがもう1つあります。

「I / Oの監視」というタイトルのセクションには、監視するパフォーマンスカウンターに関するいくつかのアイデアがあります。これらをしばらく監視し、状況がどのように変化するかを確認します。tempdbログファイルの実際の使用率も実際には50％未満でした。これは、今朝の負荷の下で拡張され、それ以来そのスペースを保持しているという考えに適合しています。

成長するサイズが必要なサイズであることに基づいて先に進みます。将来このサイズを監視し、どのドライブでも成長の余地があることを確認してください。ここの一部で提案されているように、一時ログが拡張されたときに何が実行されているかを調べ、そこで何かを調整できるかどうかを確認します。また、これらのioパフォーマンスカウンターを監視して、処理が必要かどうかを確認します。

「SQL Server 2005へのアップグレード」というタイトルの興味深いセクションがもう1つありました。これは、tempdbが2000年よりも2005年に多くの目的で使用されることを示しています（新機能、および以前はtempdbを使用しなかった既存の機能）。私は最近2005年にアップグレードしたばかりなので、これが突然問題になっている理由の一部である可能性があります。しかし、2005年へのアップグレードに関してこれを他の場所で見たのを覚えていません。これは少し苦痛です。

これは、制御不能なクロス結合クエリが原因である可能性が高いです。あなたの最善の策は、プロファイラーを使用してそれを見つけて修正することです。

それを見つけるもう1つの方法は、TempDBログファイルのサイズを制限し、どのクエリが失敗するかを確認することです。しかし、私はそれがすでに失敗していて、誰もあなたに言っていないことに賭けるでしょう。

SQLエンジンを再起動すると、ファイルは初期サイズに設定されます。すべての自動拡張ファイルに最大サイズを設定する必要があります。

一部のSQLクエリまたはストアドプロシージャが悪いことをしています-tempdbをプロファイリングして "Database：Log File Auto Grow"イベントをキャッチし、それが発生した場合は、プロファイラーとsysprocessesなどのテーブルに対するクエリを使用して見つけます悪いプロセスとは何か。

残念ながら、それは悪意のあるプロセスを追跡する昔ながらの探偵の仕事にかかっています。

tempdbログファイルのサイズをDBCC SHRINKFILE（）で変更してみましたか？その場合、[非常に小さい値]から45GB以上になるまでにどのくらいかかりますか？