小编Gab*_*abe的帖子

我们正在讨论是否对 DW 表使用 SORT_IN_TEMPDB 选项。我的理解是，使用此选项时会有更多的写入，尽管它们更具顺序性。我们有一个 SAN（它有时非常慢），所以在我们的例子中，我们希望尽可能地限制写入次数。我相信 tempdb 位于单独的 LUN（磁盘集）上。

我们的数据文件和 tempdb 文件中有足够的磁盘空间。在这种情况下，我们会从使用 SORT_IN_TEMPDB 中受益吗？

让我印象深刻的一件事是对这个答案的评论

重建索引时，您需要两倍于索引的空间 + 20% 用于排序。因此，一般而言，要重建数据库中的每个索引，您只需要数据库中最大索引的 120%。如果你使用 SORT_IN_TEMPDB，你只赢了 20%，你的数据文件中仍然需要额外的 100%。此外，在 tempdb 中使用 sort 会大大增加您的 IO 负载，因为不是将索引一次写入数据文件，而是现在将其写入一次 tempdb，然后将其写入数据文件。所以这并不总是理想的。

我们绝对不想通过慢速/可能配置错误的 SAN 增加 IO 负载。

测试这个的最佳方法是什么？通过简单地重建带有和不带有选项的表并记录时间？

编辑：我们有 8 个 tempdb 文件，每个 15GB。我们确实设置了 TF 1117/1118 标志并启用了 IFI。我们目前混合使用 sort_in_tempdb 选项和不使用它进行重建。

谢谢！

SQL Server 2012 企业版

在过去的几天里，我们已经 3 次遇到这个奇怪的错误，在 8 周没有错误之后，我被难住了。

这是错误消息：

Executing the query "EXEC dbo.MergeTransactions" failed with the following error:
"Cannot insert duplicate key row in object 'sales.Transactions' with unique index
'NCI_Transactions_ClientID_TransactionDate'.
The duplicate key value is (1001, 2018-12-14 19:16:29.00, 304050920).".

Run Code Online (Sandbox Code Playgroud)

我们拥有的索引不是唯一的。如果您注意到，错误消息中的重复键值甚至与索引不一致。奇怪的是，如果我重新运行 proc，它会成功。

这是我能找到的最新链接，但我没有看到解决方案。

https://www.sqlservercentral.com/forums/topic/error-cannot-insert-duplicate-key-row-in-a-non-unique-index

关于我的场景的一些事情：

• proc 正在更新 TransactionID（主键的一部分）-我认为这是导致错误的原因，但不知道为什么？我们将删除该逻辑。
• 在表上启用更改跟踪
• 做事务读未提交

每个表有45个字段，我主要列出了索引中用到的字段。我正在更新更新语句中的 TransactionID（集群键）（不必要）。奇怪的是，直到上周我们几个月都没有遇到任何问题。它只是通过 SSIS 偶尔发生。

桌子

USE [DB]
GO

/****** Object:  Table [sales].[Transactions]    Script Date: 5/29/2019 1:37:49 PM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

IF NOT EXISTS (SELECT * …

我有一个这样的查询：

select dbo.fn_complexFunction(t.id)
from mytable t

在SQL Sentry Plan Explorer 中，我注意到我必须运行 Get Estimated Plan 才能使查询计划包含 UDF。

运行“获取实际计划”时，逻辑读取和其他指标似乎不包括 UDF 中发生的操作。在这种情况下，使用 Profiler 是唯一的解决方法吗？

对于老式跟踪，我可以查看 sys.traces 或 SQL Server 日志以查找跟踪开始的时间。扩展事件有类似的东西吗？我遇到了这个博客条目关于使用 DDL 触发器的，但我想知道是否有更好的东西。

SQL Server 2012-2014

我将填充每加仑英里数 (MPG) 表。它来自里程表源。

目前设置如下：

  id               (primary_key)
, truck_num
, start_date
, end_date
, start_miles
, end_miles
, start_fuel
, end_fuel
, miles
, gals
, mpg

似乎有一些冗余。的miles是 (end_miles - start_miles)，对于同上gals。

我们应该预先计算这些miles和gals列并存储在数据库中吗？它肯定会使查询更容易，但会牺牲空间。mpg计算相同的问题。计算列会减慢速度，不是吗？

什么索引最有效？每周大约有 3,000 辆卡车（记录）成批插入。

我正在使用 SQL Server 2008 R2。

编辑：我将使用的示例查询

-- find average mpg for since ytd
select m.truck_num, avg(mpg)
from mpg m
join truck t on t.truck_num = m.truck_num
where start_date >= @begin_of_year and end_date <= @today
group …

我有一个 900 万条记录表，大小约为 452MB（不考虑 NC 索引）。以下是身体统计数据和列

举一个简单的例子，如果我将表转储到临时表中，实际计划显示估计高达 42GB，并且实际数据大小。见下图。

我怀疑这是由于两个 varchar(4000) 列导致估计的行大小比它们大。但是，我真的不认为 42GB 正在传输 - 不确定这怎么可能。我不知道我是否因此看到性能问题，但由于这些错误的估计，查询计划看起来很可怕。为什么在估计和实际的表扫描上查询计划如此错误？

我们想对我们的散列函数使用 MD5 而不是 SHA_256，但从 SQL Server 2016 开始，不推荐使用 MD5。我们将其用于散列（比较哪些记录已更改）。我们现在面临着使用这个函数冒着风险或使用 SHA_256 产生存储和性能开销的困境。令人沮丧的是，Microsoft 决定弃用这些功能，即使它们在某些情况下仍然有用。

该项目不是业务的关键组成部分。我们可能会选择 SHA_256，但这是正确的选择吗？新开发应该总是避免弃用的功能吗？

对于上下文 - 每天将有大约 1-2 百万个更新插入到一个 4 亿行表中，动态比较哈希字节。大约 30 列宽

https://docs.microsoft.com/en-us/sql/t-sql/functions/hashbytes-transact-sql?view=sql-server-2017

在 HashBytes 函数中选择正确的算法

由于对 DQS 的特定修复，我们在 SQL Server 2012 SP1 上安装了累积更新 #10。

由于最近发布的 SQL Server 2012 SP2 仅包含从 CU1 到 CU #9 的修复，如果我们决定更新到 SP2，是否会覆盖和删除 CU #10 中的修复？如果是这样，我们可以重新应用 CU#10 吗？或者我们是否必须等到为 SQL Server 2012 SP2 制作另一个 CU？

• http://support.microsoft.com/KB/2958429
• http://support.microsoft.com/kb/2954099