小编Jax*_*ian的帖子

DBCC FREEPROCCACHE在 Azure SQL DB 中不起作用。我还能如何强制计划以一种不会伤害生产系统的方式将自己踢出缓存（即我不能随意更改表）？这是专门为 Entity Framework 创建的 SQL，所以这些不是自我管理的存储过程 - 它是有效的动态 SQL。

（来源是糟糕的索引 -> 糟糕的统计数据等。这一切都已解决，但糟糕的计划不会消失。）

更新： 当他首先到达那里时，我选择了@mrdenny 的解决方案。然而，我成功地使用@Aaron Bertrand 的脚本来执行这项工作。感谢大家的帮助！！

我的公司在能源行业，我需要想出一个好方法来表示测量单位的转换。我已经做了一些搜索，但还没有找到一篇很好的文章，在我需要的深度上涵盖了这一点。大多数关于单位转换的信息都假设给定单元 1 有一个已知的（硬编码）转换率可以到达单元 2，这是简单的数学运算（这是我发现的最复杂的例子，但仍然无济于事）。然而，这在现实世界中并不总是正确的，对于我们必须处理的事情当然也不是这样。（抱歉写了这么长的文章——我正在尝试提供尽可能多的信息！）

棘手的示例 1： 某些转换会随时间变化，例如将 5 美元转换为欧元，反之亦然。这听起来似乎与能源无关，但它确实与能源商品市场有关（想想股票市场）。

棘手的例子 2：（ 过度简化）一些天然气比其他天然气燃烧得更热。此外，天然气可以基于气体中的能量（例如Therms）或基于所述气体的体积（例如1000 立方英尺的MCF）来测量/存储，还有其他可能性（例如作为吨用于质谱）。汽油的一个类比是 1 加仑 87 辛烷无铅提供的能量比 1 加仑 93 辛烷无铅提供的能量少。

棘手的例子 3： 除了这些计量单位之外，我们还经常需要处理费率，例如$ per Therm或€ per MCF。因此，我们需要一些方法来与这些利率和如何将它们与基本单位工作，所以如果我们需要从转换$每千卡至每MCF€，我们可以和它们使用同样的发布速率转换从千卡至MCF。

棘手的例子 4： 以前，我非常松散地使用术语能源，有时可能是错误的。从现在开始，这种情况正在发生变化。所以最后一个曲线球是我们同时处理Energy和Power。对于电力，这意味着千瓦时与千瓦（尽管是雅虎问答，但这是一个相当好的解释）。数据类比：这就像比较下载的总MB数据与您的Mbps您的 ISP 为您提供的带宽。与数据一样，能源需要时间才能交付。继续进行数据类比，我们可能需要计算一段时间内消耗的平均有效带宽，因此假设在 1 …

我的背景：我是一名开发人员/架构师，而不是 DBA。对不起！

所以我们有一个 ~400 表 75GB 的数据库。我运行 Profiler 大约 24 小时（“调优”模板减去LoginName），并在跟踪文件中记录了大约 7GB 的使用量。然后，我针对我们的生产数据库（下班后）在此跟踪文件（无分区，保留聚集索引，PDS 推荐：索引）上运行数据库引擎优化顾问。我给了它大约 4 个小时的时间来分析。这是我得到的总结结果：

对我来说，看起来“错误”的事情是：

1. 它只调整了 ~530k 查询中的 ~9k
2. 它建议我删除大量索引（实际上，其中大部分）
3. 它建议我创建 0 个索引

这听起来对吗？我预计它会删除我的大部分索引，但随后会创建大量新索引。另外，如果分析 9k 查询需要 4 个小时，那么我是否可以考虑正常一天的使用价值？与大多数大型数据库相比，我们的数据库消耗相当轻（总共约 50 个用户）。

我想我要么误解了什么，要么只是做错了什么。

我们有许多表（约 1M 条记录），其中有一列定义为：[GlobalID] [uniqueidentifier] NOT NULL自动填充newid(). 我们使用此 ID 跨多个系统、数据库、文件导入/导出等同步数据。

对于此列，我们创建了以下索引：

CREATE UNIQUE NONCLUSTERED INDEX [IxUx_XXXXXX_GlobalID] ON [dbo].[XXXXXX] 
(
    [GlobalID] ASC
)

正如预期的那样，这个索引很快就会变得碎片化，所以我们必须保持重建。然而，这正是我们遇到问题的地方。我的维护脚本通过并重建超过 x% 碎片的所有索引ONLINE=ON总是永远挂在这些索引上。当数据库几乎完全空闲时，我试图让一个运行超过 3 个小时而没有成功。只是为了踢球，我什至将数据库置于单用户模式，没有任何改变。我也试过ONLINE=OFF, 再次没有改变。不过，我是能够简单地丢弃/创建索引，并将其〜15秒内完成！

为了确保我的维护脚本没有什么可笑的，我手动尝试重建这些索引但没有成功。我使用的脚本是：ALTER INDEX IxUx_XXXXXX_GlobalID ON [dbo].[XXXXXX] REBUILD WITH (ONLINE=ON)它似乎永远不会成功。考虑到我可以在 15 秒内删除并重新创建它，3 小时对于在空闲数据库上看到成功来说已经绰绰有余了。

现在，我已经更改了我的维护脚本以过滤掉名称中带有“GlobalID”的索引，然后有一个删除/创建这些索引的后续脚本。直到我们开始对这些类型的列进行命名变体（即，我们需要一个 uniqueidentifier 用于其他目的）之前，我们一直在这样做。

知道为什么重建这些索引永远不会在合理的时间内完成吗？我看到这种情况发生在大约 12 个表中，所有表都具有基本相同的列/索引。