如何配置 SQL Server 以便“数据库 A”中的活动对“数据库 B”中的用户影响最小
上下文
我们的（非常大的）生产 SQL Server 上有很多运行各种“遗留应用程序”的数据库，每个数据库用于特定客户的应用程序实例。
问题
如果“流氓用户”运行非常昂贵的查询——有时来自报告，有时来自应用程序——它会导致“其他数据库”缓慢爬行。
[我知道“根本问题”是昂贵的查询；程序员不应该让它们运行。密集报告应该运行一个单独的报告数据库。程序员应该在大数据集等上进行测试。我的问题与“隔离”数据库对彼此的影响有关。]
我怀疑，但我还没有确认问题出在“tempdb”中，SQL Server 用于排序的临时区域/数据库无法放入内存中。
我看过帖子指出将 tempdb 传播到多个文件。这会有帮助吗？
/sf/ask/50390861/ http://logicalread.solarwinds.com/sql-server-tempdb-best-practices-multiple-files-w01 /#.VdzGxrNv4Uw
背景：谨慎的 DBA
我们已经被收购了几次，我们最新的霸主拥有 DBA，他们小心地保护他们的生产数据库服务器。
总的来说这是好的。
但是，我们遇到了开发人员和 DBA 之间的一个争论点：他们不会对生产数据库服务器运行跟踪。
我们作为开发人员的经验：SQL Server 跟踪 + RML 实用工具
过去，当应用程序实例运行缓慢时，我们会通过 .sql 脚本运行跟踪，压缩输出，然后使用 Microsoft 的 RML 实用程序对其进行处理。
请注意，我们不运行基于 GUI 的分析器工具，因为这会显着降低性能（数据库需要等待更新 GUI）。这些跟踪只是“记录活动”到数据库服务器的本地文件系统。我们的脚本一次运行指定分钟数（例如 10 分钟）的跟踪。
跟踪和 RML 实用程序的组合效果很好：报告易于使用。它显示热点（见下文），报告提供有用的信息，它们允许深入了解实际执行计划等。它比 Oracle 提供的任何东西（或至少几年前）都要好得多。
（热点：如果一个查询耗时 1/10 秒，但执行了 400,000 次，它会出现在报告中，高于执行一次需要 30 秒的查询。）
这些年来，我做了一些表演工作。我的经验是，从“真实负载下的真实数据库”中捕获“实际数据”胜过程序员“猜测”并模拟他们想象的问题。这就是为什么我认为 SQL Server 跟踪几乎是解决问题的“银弹”。
我的问题