問題タブ [tempdb]

新しいマシンにSQL Server 2005を新規インストールする予定で、注文する必要があります。SQL Server インスタンスの全体的なパフォーマンスにとって、 tempdb のチューニングが非常に重要であることはわかっています。

CPU (またはコア?) と同じ数の tempdb ファイルを作成することがベスト プラクティスであることを読みました。あれは正しいですか？ハードディスク/RAID セットアップ構成など、他に注意すべき推奨事項はありますか?

ありがとう！

本番SQLServerでいくつかの問題が発生しています。

サーバー：デュアルクアッドコアXeon 8GBRAMシングルRAID10アレイWindows2003サーバー64ビットSQLServer2005標準64ビット

現在、マシンには約250MBの空きRAMがあります。SQLServerには約6GBのRAMがあり、監視ソフトウェアによると、SQLServerに割り当てられたRAMの半分だけが実際に使用されています。

私たちのメインデータベースは約20GBで、約12GBが任意の頻度で使用されています。tempdbは700MBです。両方とも同じ物理ディスクアレイにあります。

さらに、Filemonを使用すると、tempdbファイルに長さ65536の書き込みが100または1000あることがわかりました。ディスクキューの長さは、ほぼ80％の時間で100を超えていました。

だから、ここに私の質問があります-

1. tempdbにこれらすべての書き込みが発生する原因は何ですか？私たちがいつもそんなに多くの活動をしてきたかどうかはわかりませんが、それは過度に思え、これらの問題は最近のものです。

2. サーバーにメモリを追加するだけでよいですか？

3. 高負荷サーバーでは、tempdbファイルとdbファイルを別々のアレイに配置する必要がありますか？

MS-SQL で「永続的な」一時テーブルを持つことは可能ですか? 私が言いたいのは、現在、グローバル一時テーブルを生成するバックグラウンド タスクがあり、それが他のさまざまなタスクで使用されているということです (これが、グローバルにした理由です)。残念ながら、テーブルが使用されなくなると、SQL によって自動的に削除されます。これは、再構築するためにキューに入れるだけなので、システムによって適切に処理されますが、理想的には、1 日に 1 回だけ構築されるようにしたいと考えています。したがって、理想的には、「1時間これに何も触れない場合は削除する」など、タイムアウトパラメータを設定するようなものを設定できます。

DB の管理 (断片化、ログの増加など) に関連する頭痛の種が増えるため、既存の DB には本当に入れたくありません。これは、データを効果的にロールアップし、24 時間のみ有用であり、より多くを占有するためです。 1 ギガバイト以上の HD スペース。

最悪の場合、私の計画は、tempdb と同じドライブに別の DB を作成し、それを PseudoTempDB のように呼び、自分で削除を処理することです。

どんな洞察も大歓迎です！

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

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

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

SQL Server 2000システムには、無制限に大きくなるように見えるtemplog.ldfファイルがあります。しかし、確認すると、（DBCC OPENTRANを使用して）tempdbに開いているトランザクションがないことも、tempdb内で明示的なトランザクションを使用することもありません。

ただし、ストアドプロシージャ内で一時テーブルを使用しています。そして、ASP.NETデータアクセスオブジェクトが舞台裏で何をする可能性があるかを誰が知っていますか？データベースはASP.NETWebサイトをサポートしています。

とにかく、tempdb.mdfファイル（tempdbデータファイル）はかなり妥当な700MBです。templog.ldfファイルは1日で30GBまで増大する可能性があります。ディスク容量が不足していなければ、おそらくもっと多いでしょう。ストアドプロシージャに#tablesを明示的にドロップしませんが、mdfファイルが非常に大きくなることはありません。

未処理のトランザクションがないのに、なぜトランザクションログが大きくなるのですか？トランザクションログはスペースを再利用しますか？また、DUMP TRAN WITH NO_LOGは、ファイルを縮小せず、TRUNCを介したCHECKPOINTイベントも行いません。tempdbでログオンchkptが有効になっています。SQL Serverを停止すると、tempdbがクリアされます（おそらくDBCC SHRINKFILEはクリアしますが、私はそれを実行していません）。

ご協力いただきありがとうございます！

私は理解しようとしていtempDBますが、以下は私の頭に浮かぶ疑問です。

1. のデータの寿命はtempDB? クエリが何らかの処理を行っており、それを実行するためOrder Byに使用しているとtempDBします。このクエリが終了した後、他の誰かが を利用するクエリも実行しますtempDB。2 番目のクエリは、最初のクエリによって書き込まれたレコードを検索しますか、tempDBそれとも削除しますか?
2. SQL エンジンによって内部に作成された目に見えるテーブルはありますか? tempDBこのクエリによってどの一時テーブルが作成されたかを知るにはどうすればよいですか? これらの一時テーブルに名前を付けるための SQL エンジンが従う命名規則はありますか?

私は初めてなtempDBので、そのようなばかげた（もしあったとしても）質問をすることを許してください:-)

誰かがtempDBについて学ぶのに役立つ良いリソースを教えてくれたらとてもうれしいです.

my_report_user実行時にユーザー名でデータベースに接続するレポートがあります。レポートには多数のエンド ユーザーが存在する可能性があります。また、実行ごとに、データベースへの新しい接続が作成されますmy_report_user(接続プールはありません) 。

一度だけ作成できると思われる結果セットがあり (レポートの最初の実行時である可能性があります)、他のレポートの実行ではその内容を再利用できます。基本的に、レポートを実行するたびに、この結果セット (一時テーブルとして保存) が存在するかどうかを確認する必要があります。存在しない場合は、その結果セットを作成します。それ以外の場合は、利用可能なものを再利用します。

local一時テーブル (#) または一時テーブル (##)を使用する必要がありますglobalか?

誰かがそのようなことを試したことがありますか？（ほぼ同時のレポート実行など）

編集: Sql-Server 2005 を使用しています

一時DBが指数関数的に増大する本番サーバーで深刻な問題に直面しています。SQLサービスを再起動せずにtempDBスペースを回復する方法はありますか？

乾杯カンナン。

SQL 2005 サーバーに巨大なクエリがあります。これは毎日 1 回実行する必要がありますが、このクエリを実行すると一時データベースが 2GB から 48GB に増加します。このクエリが単一のテーブルで (~120 列) の 80K レコードを追加/更新するときに tempdb が成長している理由を最適化または見つける最善の方法は何ですか?

tempdb がそれほど大きくならないこのクエリに対して、どうすればよいでしょうか?

任意の提案をいただければ幸いです。

注: このクエリには、temptables、テーブル変数、または CTE はありません。ただの束

私たちのアプリケーションは、顧客のマシンで別のアプリケーションと一緒に実行されます。これは同時実行性に明らかに悪影響を与えるため、tempdb で長時間実行されるロックを回避するためにいくつかの努力を払いました。ただし、他のアプリケーションは次のようなことを行います。

begin transaction
create #Table(...);
#Table(....) 値(...) に挿入します。
operation_for_totally_six_seconds()。
専念;

操作には時間がかかるため、アプリケーションは他のアプリケーションがロックを取得するのを待ってスタックします。

現在、たとえば SQL Server に別の tempdb を割り当てるように指示するなどして、自分のアプリケーションを他のアプリケーションから分離する方法があると期待していますが、方法は見つかりませんでした。これはどういうわけか可能ですか、それとも別の mssql インスタンスにデータベースをインストールする解決策ですか?

よろしく、 イェンス・ノルデンブロ