如何配置 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 跟踪几乎是解决问题的“银弹”。
我的问题