我们有一组运行在同一虚拟服务器上的 SQL Server 实例 (2008 R2)。每个实例代表我们开发周期中的一个阶段（开发/测试/阶段/等）。在任何给定的时间，所有实例都需要在线，但负载往往会被隔离到一个实例，这取决于我们在发布生命周期中的位置。
SQL Server 似乎会抓取并保存我们设置为最大值的任何内存量。我想知道是否有任何方法可以将实例配置为“智能”内存消耗，以便它们在需要时不会相互阻止获取内存。
我们使用内置的维护计划来重新索引（和备份等）我们的生产 SQL Server。我们目前遇到的问题是，经过几个月的平稳运行，本周重新索引任务开始随机失败。在过去六晚中有三晚失败（每晚运行），并且在 ASPNETDB 数据库上总是失败。这个数据库是微软的 ASP.Net 用户/角色数据库（我讨厌 BTW，但那是另一回事了）。
如果我从重新索引数据库列表中删除失败的数据库，任务就会成功。如果我删除除了失败的数据库之外的所有其他数据库，任务仍然会成功。如果我按照上面的两个步骤，然后立即正常运行任务，它就成功了。我看不出这有什么押韵或理由。
当任务失败时，日志消息看起来像我在下面粘贴的内容（我看不到任何错误）。该消息总是以最后一个语句“ALTER INDEX [PK__aspnet_P__32...”结束。
有什么想法可能会发生在这里吗？
消息以用户身份执行：mydbname\i2SQLclstsvc。...0.2500.0 为 64 位 版权所有 (C) Microsoft Corporation 2010。保留所有权利。开始时间：8:46:39 PM 进度：2012-03-15 20:46:40.33 来源：{3D0CB67E-0B04-419A-BA8F-CDD8F0519612} 正在执行查询“DECLARE @Guid UNIQUETEIDENTIFIER”。 : 100% 完成 End Progress Progress: 2012-03-15 20:46:54.74 Source: Rebuild Index Task Executing query "USE [ASPNETDB] ".: 2% Complete End Progress Progress: 2012-03-15 20:46:54.76来源：重建索引任务执行查询“ALTER INDEX [aspnet_Applications_Index] ON [dbo].[...”。：4% 完成结束进度进度：2012-03-15 20:46:54.76 来源：重建索引任务执行查询“使用 [ASPNETDB] ".: 6% 完成结束进度进度:C93A4C98014935CB] ON [d...".: 9% complete End Progress Progress: 2012-03-15 20:46:54.76 Source: Rebuild …
一个重新索引脚本最近在我们的开发环境，集运行ALLOW_ROW_LOCK = FALSE和ALLOW_PAGE_LOCKS = FALSE数据库中的所有索引。
这是在测试新的重新索引脚本时完成的 - 这不是故意完成的。
运行此脚本后，我们立即开始看到大量我们通常从未见过的死锁。
我有一个相对较大的表，它以一种方式访问，正好通过一个查询（在读取端）。
查询按两列（均为bit）过滤表，并按第三列（整数）排序。请注意，查询命名列（它实际上不使用“*”）。“TOP 1000”是有意的，是生产查询的一部分：
生成了查询——不知道为什么它会以这种方式生成。
SELECT TOP 1000
*
FROM
MyTable m
WHERE
m.IsFlag1 != 1
AND m.IsFlag2 != 1
ORDER BY
m.SomeId
我有一个覆盖索引，主列是IsFlag1和IsFlag2。
执行计划显示并在此索引上查找索引，然后进行排序。根据执行计划，排序占查询成本的 97%。
我尝试添加SomeId为索引的主列（第三列），但执行计划保持不变。
然后我尝试添加一个仅使用 SomeId 作为主列的覆盖索引，保留原始索引。执行计划然后对新查询进行索引扫描，操作成本显着降低（并且在功能上更快）。
说了这么多，我想尽可能地优化这个查询。有没有办法修改索引，以便它简单地进行查找？
非常简单的问题：备份数据库的开发和 QA 实例是标准/最佳实践吗？
假设模式信息保存在某种形式的源代码控制中。
我正在帮助解决 SQL Server 机器上的一些问题。曾经运行没有问题的应用程序现在因连接池错误而失败，并且没有对应用程序进行任何可能导致此新问题的更改。
在调查连接池错误的可能原因时，我遇到了这篇文章，其中将“最大工作线程”设置作为可能的原因。我检查了生产服务器，此设置为 54（开发中为 89，QA 中为 79）。