2

SQL Server 2000の実稼働環境では、突然（つまり、過去3日間）何かが原因でtempdbデータファイルが非常に大きくなりました（データベースが10ギガしかない場合は45ギガ）。昨日、それが再び起こった後、私たちはデータベースを縮小し、問題なく主要なバッチプロセスを個別に実行しました。しかし、今朝、データベースは45ギガまでバックアップされました。

このデータベースが非常に大きくなる原因を見つける簡単な方法はありますか？理想的には、今日見ることができるものですが、それが利用できない場合は、明日その情報を取得するように設定できるものです。

ところで：データベースを縮小すると、数秒以内にスペースが返されます。

4

5 に答える 5

2

ジミーに同意すると、SQL プロファイラーを使用して、非常に集中的に作成された一時オブジェクトを見つける必要があります。これは、いくつかのレポートなどを使用する一時テーブルである可能性があります。

于 2009-07-13T15:02:04.613 に答える
1

問題の原因に確実につながったので、皆さんの回答に感謝したいと思います。

SQL プロファイラーをオンにすると、大量のバルク ロードが表示されました。「問題のある」ジョブをmysqlでも動作するように移動するプロジェクトに取り組んでいるので、おそらく今のところ様子を見るだけです。

于 2009-07-15T01:59:01.403 に答える
0

インデックスを再構築するジョブを実行していますか？SORT_IN_TEMPDBを使用している可能性があります

または、並べ替えを行うその他の大きなクエリは、tempdbを拡張する可能性があります

于 2009-07-13T15:05:05.593 に答える
0

これは、TempDBが設定されているリカバリモデルと関係がある可能性があります。BULK-LOGGEDではなくFULLに設定できます。完全復旧では、バックアップが実行されるまでトランザクションログのサイズが増加します。

データファイルのサイズとトランザクションログのサイズを比較してください。

于 2009-07-13T15:05:06.670 に答える
0

私はDBAではありませんが、いくつかの考えがあります：

  • 作成されているが削除されていない一時テーブルがある可能性はありますか? ##tempTable?
  • 大きな一時テーブルが作成 (および削除) されている可能性がありますが、スペースは再利用されていませんか?
  • システムが一時テーブルを使用する可能性のある場所で、何らかの種類の一括読み込みを行っていますか? (できるかどうかわかりませんが) tempdb の自動圧縮をオンにしていただけますか?
于 2009-07-13T15:41:14.570 に答える