私が現在取り組んでいる BI プロジェクトは、(多すぎる) 一時テーブルを使用する SP に基づく複雑なプロセスからデータを受け取ります。これは私たちが制御できないものです (または私が変更したはずです)。
このプロジェクトでの私たちの部分は、主に SSIS に基づいています。
プロセスは正常に実行されますが、tempdb が比較的早くいっぱいになり、エラーが発生し始めます。
私は2つのことを探しています:
最初の質問は、tempdbがいっぱいになる理由ですが、一時的なテーブルの過度の使用が原因である可能性が最も高いと思われる、塗りつぶしのソースをすでに特定しています。より少ないリソースを使用するようにストアドプロシージャを作り直すことはオプションではないように聞こえます（間違っている場合は修正してください）。
次に私が見るのはtempdbのためのスペースを追加することですが、それは包帯であり、あなたがすでに試したことがあると確信しています。
できることは、tempdbがどのように定義されているかを確認することです。あなたの初期のサイズと成長パターンは何ですか？tempdbを右クリックしてプロパティを選択するか、DBAにこれを実行させます。SQL Serverサービスが再起動するたびに、tempdbが削除されて再作成され、サイズ設定と拡張のデフォルトは本番ボックスの適切な値ではありません。10％の成長パターンで8MBのデータと1MBのログが表示される場合は、インスタンスを使用するすべての人のパフォーマンスを向上させる絶好の機会があります。詳細については説明しませんが、これによりファイルが少し大きくなり、パフォーマンスが低下します。tempdbパフォーマンスの最適化に関する正しい初期サイズ設定とmsdnによるTempDBパフォーマンスの最大化。tempdbの成長を修正しても、魔法のように問題が解決することはありませんが、物事をいじくり回している場合は、問題はありません。
制御できるのはSSISです。SSISは、ロードしているテーブルごとにこれらのストアドプロシージャなどを呼び出していると思いますか？複数のパッケージやデータフローが並行して実行されていると仮定して、それらのシリアル化を検討できます。これにより、合計実行時間が長くなりますが、tempdbのコストが長期間にわたって分散されるはずです。
もう1つのオプションは、パッケージ内の分離レベルを確認することです。私はこの分野に弱いですが、分離レベルが異なればtempdbの使用に異なる影響を与えることを理解しています。私の、おそらく欠陥のある理解は、Snapshotは基本的にtempdbで更新しているテーブルのコピーを作成して、他の人がテーブルにアクセスし続けることができるようにし、完了したときにのみそれらの変更を実際のテーブルにプッシュします。これは、異なる分離レベルよりも多くのtempdbスペースを消費します。ただし、景品はありません。したがって、デフォルトのSerializableに切り替えると、tempdbの使用量は少なくなりますが、ブロッキングが高くなり、同時アクセスが少なくなります。
できません！tempDBに大量のデータを作成するプロセスA（あなたが言及した複雑なプロセス）がある場合、プロセスBを使用してそのデータを消去できます。そうしないと、プロセスAが壊れる可能性があります.
あなたができないと言ったのは知っていますが、唯一の解決策は、プロセスAを改善する方法を見つけて、スペースを使いすぎないようにすることです。または一時DBのスペースを増やします