我目前正在从事的BI项目从使用（也是）许多温度表的SPS中的复杂过程中接收到其数据。这是我们无法控制的东西（或者我会更改它）。
我们在该项目中的一部分主要基于SSI。
流程运行良好，但是tempdb填充相对较快，然后我们开始遇到错误。
我正在寻找两件事：
- 如何防止tempdb"溢出"（或至少放慢速度）？
- 当TempDB溢出时，如何清理tempdb？（最好使用SSIS）
第一个问题是tempdb为什么要填充，但您已经确定了填充的来源，因为很可能是由于过多的临时表用法所致。听起来好像在重新加工存储过程以使用更少的资源不是一个选项（如果我错了，请更正我）。
我要看的接下来是为tempdb添加更多空间，但这是绷带，我敢肯定您已经尝试过。
您可以做的事情是查看tempdb的定义。您的最初大小是多少，增长方式是什么？右键单击tempdb并选择属性或使DBA执行此操作。每当SQL Server服务重新启动时，tempDB都会被删除并重新创建，并且尺寸和增长的默认值并不是生产框的理想值。如果您看到具有10％增长模式的8 MB数据和1MB日志，那么您将有一个很好的机会来提高使用该实例的每个人的性能。我不会详细介绍细节，但这导致了很少的文件增长，这是不好的。通过正确的初始尺寸和MSDN最大化TEMPDB性能，以优化TEMPDB性能。修复tempdb的增长不会神奇地使您的问题消失，但是如果您在修补事情，它不会受到伤害。
您可以控制的一件事是SSI。我认为SSIS称这些存储的Procs，以及您加载的每个表格？假设您有多个软件包和/或数据流并行运行，则可以查看它们序列化。这将增加您的总运行时间，但应该在更长的时间内扩散您的tempdb成本。
另一个选择是查看包装中的隔离水平。我在这个领域很弱，但我的理解是，不同的隔离水平对tempdb使用的影响不同。我可能有缺陷的理解是快照基本上使您在tempdb中更新的表的副本，以允许其他人继续访问表，只有在完成时，才能将这些更改推回真实表中。与不同的隔离水平相比，这将花费更高的TEMPDB空间。不过，没有免费赠品，因此，如果将其切换到可序列化的默认情况下，它可能会降低tempdb的使用情况，但以较高的阻止/不同时访问为代价。
参考
- 优化tempdb（pdf）
你不能！如果您有一个流程A（您提到的复杂过程）在tempdb上创建大量数据，则可以使用过程b来清洁该数据，否则您可能会违反A流程A。
我知道您说您不能，但是唯一的解决方案是找到一种改进过程的方法，因此它不会使用太多空间。或增加温度db