相关疑难解决方法(0)

查询是包含许多分组级别和聚合操作的单个选择。使用 SET ARITHABORT ON 只需不到一秒钟，否则需要几分钟。我们已经在 SQL Server 2000 和 2008 上看到了这种行为。

两台服务器，Development 和 Live。实时服务器是一个 Amazon RDS SQL Server Web 实例。两台服务器都具有相同的架构和数据。几何列上有一个很好的空间索引。在我的开发服务器上，查询在 < 30 毫秒内执行。在实时服务器上，查询需要 > 20 分钟。

检查执行计划表明它们完全不同。一方面，在我的开发环境中，查询是并行化的，而在实时服务器上则不是。

• 我重建了索引并重新生成了统计信息。
• 我无法解释巨大的差异。
• 服务器的 DOP 相同。
• 在执行查询期间，实时服务器的 CPU 受到 100% 的冲击。

如果您对原因或如何最好地诊断问题有任何见解，我将不胜感激。

DECLARE @geoBoundary geometry;
SET @geoBoundary = geometry::STGeomFromText('POLYGON((407439.5 108792.25, 408022.5 108792.25, 408022.5 108575.75, 407439.5 108575.75, 407439.5 108792.25))', '0');

SELECT
     ogr_geometry.ToString() AS strGeometry
    ,ogr_geometry
FROM inspire as geo
WHERE geo.ogr_fid IN
(
    SELECT
        geo.ogr_fid
    FROM .inspire as geo
    WHERE
    (
        (@geoBoundary.STContains(geo.ogr_geometry) = 1)
    )
    UNION
    SELECT
        geo.ogr_fid
    FROM .inspire as geo
    WHERE
    (
        (@geoBoundary.STOverlaps(geo.ogr_geometry) = …

我有一个带有 5 个实例的生产盒。

版本：SQL Server 2014 SP3 企业版。

我发现即使机器分配了大约 400GB 的内存，所有 5 个实例的组合MAX MEMORY设置也小于 200GB。

实例不会受到内存压力的影响，但是由于我们已经分配了该内存，所以不使用它是一种浪费。

我想将其增加到更高的值，为操作系统保留 10%（某些实例的分配将高于其他实例）。

不过，我以前从来没有对这个设置做过这么大的增加。

我知道这是一个不需要重启的动态设置，但是，我想知道以下几点：

• 我应该分两个阶段增加（即增加一半，等待一周然后再次增加）？
• 如果 SQL Server 突然有更多的内存可以使用，是否会突然中断（或导致性能下降）？

我们没有启用内存设置中的锁定页面，也没有启用跟踪标志 834。

上周五，我将 SQL Server 实例从 2005 Enterprise Edition 迁移到安装了 SQL Server 2012 Enterprise Edition 的全新 Windows Server 2012 服务器。从那时起，用户开始抱怨应用程序的性能。

以下是有关服务器的一些信息：

• VMWare 5.5 上的虚拟服务器
• 4 个 vCPU 和 24 Gb RAM。在之前的配置中，10 Gb 是必要的，但 tempdb 数据库比我设置的要小（几乎 6Gb）
• 我现在已将最大内存目标设置为 22 Gb，并且 tempdb 完全在缓冲池中
• 迁移后（使用数据库镜像执行），我运行了更新统计、索引重建和其他维护命令

我不知道在哪里可以找到答案。如果除 SQL Server 实例之外的所有内容都相同（VM、磁盘等），那么对我来说，问题出在 SQL Server 配置中，但在哪里呢？我尝试了一些更改，但似乎没有一个有用。

你有什么想法？

来自评论的附加信息

• 我运行了 sp_Blitz，它给了我一些信息，但 SQL 2005 没有什么新东西（例如存储速度慢）
• 内存消耗 (20Gb + ) 主要是由于 tempdb (6Gb)，其余大部分由应用程序数据库占用
• PLE 流，有时会下降到 150。在一天开始时，大部分数据都在缓存之外
• 之前服务器上的最大内存设置为 10Gb
• 我们使用 Idera 诊断管理器
• 最大服务器内存设置为它在前一个服务器上的值的两倍。
• 页面寿命至少每天两次低于 150

sp_BlitzIndex 分析

我开始使用 sp_BlitzIndex 进行分析，除了编写糟糕的代码外，它还显示了这一点：

• 主动索引：总锁等待时间 > 5 …

我们在 SQL Server 2008 R2 标准版上有一个 30 GB 的数据库。昨天我们备份了数据库并将其恢复到一个不同的虚拟机，它的规格与之前的机器完全相同——唯一的例外是新虚拟机有更多的内存。

但是我们发现旧虚拟机的性能比这个新虚拟机好得多。我的问题是：

1. 在这样的恢复之后，我们是否应该重新创建/刷新数据库中的所有索引？如果是这样，那么是否有一种好方法可以轻松刷新所有索引（而不是一次一个索引）。

2. 是否还有我们遗漏的其他明显步骤 - 我们没有内部 DBA，因为我们在数据库方面所做的工作并不多。

我在 SQL Server 2014 SP2 中有一个 T-SQL 存储过程，它在服务器上花费的时间是我在本地环境中花费的时间的 3 倍。

我将本地数据库恢复到服务器上的数据库，因此架构和数据是相同的。

我是一名程序员，并不是真正的 DBA，所以请耐心等待。

在您查看 XML 之前，执行计划似乎是相同的。在我的本地环境中，Stream Aggregate 用于其中一个查询以进行不同的选择，而在服务器上，它看起来像是 Sort 与散列一起使用。

服务器的处理器比我的（野兽）本地机器少的事实似乎导致了这个问题。每个查询在服务器上都需要更长的时间。这可能是在服务器上选择排序/散列而不是流聚合的原因吗？

有没有办法强制流聚合？

这是存储过程的 SQL：http : //pastebin.com/kkXM3Bsf

这是我本地环境的执行计划：http : //pastebin.com/0u7SHxnM

这是服务器的执行计划：http : //pastebin.com/9sE9DfM0