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のログファイルがいっぱいになり続け、autogrowが設定されている場合、より多くのスペースが必要になるとログファイルが大きくなります。これが、ログファイルが増え続ける理由です。
要約すると、あなたが説明する症状の最も可能性のある根本原因は、ユーザーおよび/またはtempdbデータベース/ログファイルのディスク/ lunからの不十分なI/O応答によるものです。
ソリューション：
Tempdbログファイルが75％いっぱいになったときに発生するアラートを設定し、それに応じて手動の「チェックポイント」を強制するジョブを実行することにより、I/Oサブシステムを整理しながら問題を回避しました（自動システムよりも優先されます）チェックポイント）、tempdbログを消去して、無期限に自動成長するのを防ぎます。他の不測の事態に備えて、ログファイルを自動拡張のままにしておくことをお勧めします。また、修正を適用した後、tempdbログファイルのサイズを環境に応じて意味のあるものに減らすことを検討することを強くお勧めします。
お役に立てれば。
Temp dbで設定されている復旧モデルは何ですか？シンプルに設定されていない場合は、シンプルに設定します。これはそれが成長しないようにする必要があります。それがすでにSimpleに設定されている場合、対処する必要のある根本的な問題があり、ファイルを縮小しようとしても、根本的な原因ではなく、問題の症状のみが処理されます。
私はこの数時間を読んで、これについてメモをとっています
http://technet.Microsoft.com/en-gb/library/cc966545.aspx
そこには多くの詳細と問題のトラブルシューティングに関する提案があります。 tempdbが拡大して止まらない場合を除いて、必要な容量を占有しているだけで、最初はそのサイズに設定されているはずです。 tempdbに必要なスペースの見積もり、およびtempdbでスペースを占有している可能性があるものを追跡するセクションがあります。この結果、最初に行うのはtempdbをより大きなドライブに移動し、そこから何が起こるかを確認することです。
どの機能がログを使用するかを示す 'tempdb logging for tempdb logging'というタイトルのセクションがあります。 tempdbを使用します。
'Monitoring I/O'というタイトルのセクションには、監視するパフォーマンスカウンターに関するいくつかのアイデアがあります。私のサーバーをざっと見てみると、たぶんioボトルネック領域。これらをしばらく監視し、状況がどのように変化するかを確認します。 tempdbログファイルの実際の使用率も実際には50％未満でした。これは、今朝の負荷によって拡張され、それ以来そのスペースを保持しているという考えに適合しています。
成長するサイズが必要なサイズであることに基づいて先に進んでいます。将来このサイズを監視し、どのドライブでも成長の余地があることを確認してください。ここの一部で提案されているように、一時ログが拡大するときに何が実行されているかを調べ、そこで何かを調整できるかどうかを確認します。また、これらのioパフォーマンスカウンターを監視して、処理が必要かどうかを確認します。
'SQL Server 2005へのアップグレード'というタイトルの興味深いセクションがもう1つありました。これは、tempdbが2000年よりも2005年に多くのことに使用されていることを示しています（両方の新機能） 、および以前はtempdbを使用していなかった既存の機能）。私は最近2005年にアップグレードしたばかりなので、これが突然問題になっている理由の一部である可能性があります。 2005年へのアップグレードに関してこれを他の場所で見たのを覚えていません。これは少し苦痛です。
一部のSQLクエリまたはストアドプロシージャが悪いことをしています-tempdbをプロファイリングして "Database：Log File Auto Grow"イベントをキャッチし、それが発生した場合はプロファイラーとsysprocessesなどのテーブルに対するクエリを使用して見つけます悪いプロセスとは何か。
残念ながら、不正なプロセスを追跡するのは昔ながらの探偵の仕事です。
TempdbログファイルのサイズをDBCC SHRINKFILE（）で変更してみましたか？その場合、[非常に小さい値]から45GB以上になるまでにどのくらいかかりますか？
これは、制御不能なクロス結合クエリが原因である可能性が高いです。あなたの最善の策は、プロファイラーを使用してそれを見つけて修正することです。
それを見つけるもう1つの方法は、TempDBログファイルのサイズを制限し、どのクエリが失敗するかを確認することです。しかし、私はそれがalready失敗であり、誰もあなたに言っていないことに賭けるでしょう。
SQLエンジンを再起動すると、ファイルは初期サイズに設定されます。すべての自動拡張ファイルに最大サイズを設定する必要があります。