标签: sql-server-2016

在我撰写本文时，我仍在等待 SQL Server 2016 的正式发布，以便我们可以探索其“始终加密”功能的实用性。

我只想知道 SQL Server 2016 中的 Always Encrypted 和当前可用的透明数据加密之间的具体区别是什么，以便我们可以为未来的项目做出正确的决定。

我遇到了一个奇怪的问题，SQL Server 2016 标准版 64 位似乎将自己限制在分配给它的总内存的一半（128GB 中的 64GB）。

的输出@@VERSION是：

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 2017 年 12 月 22 日 11:25:00 版权所有 (c) Windows Server 2012 R2 Datacenter 6.3 上的 Microsoft Corporation 标准版（64 位）（内部版本 9600：）（管理程序）

的输出sys.dm_os_process_memory是：

当我查询时sys.dm_os_performance_counters，我看到Target Server Memory (KB)是在131072000和Total Server Memory (KB)是 at 的一半以下65308016。在大多数情况下，我认为这是正常行为，因为 SQL Server 尚未确定它需要为自己分配更多内存。

然而，它已经“卡住”在 64GB 左右超过 2 个月了。在此期间，我们对一些数据库执行了大量内存密集型操作，并向实例添加了近 40 个数据库。我们总共有 292 个数据库，每个数据库都有 4GB 的预分配数据文件和 256MB 的自动增长速率和 2GB …

出于习惯，我从不SELECT *在生产代码中使用（我只将它用于临时废料查询，通常是在学习对象的模式时）。但是我现在遇到了一个案例，我很想使用它，但如果我使用它会觉得很便宜。

我的用例是在一个存储过程中，其中创建了一个本地临时表，该表应始终与用于创建它的基础表相匹配，无论何时运行该存储过程。临时表是在很晚之后填充的，因此快速创建临时表而不冗长的方法SELECT * INTO #TempTable FROM RealTable WHERE 1 = 0尤其适用于具有数百列的表。

如果我的存储过程的使用者不知道动态结果集，那么我将服务出售给 有什么问题SELECT *吗？

SQL Server 实例是可访问的，而且似乎没问题。

Microsoft SQL Server 2016 (SP1-CU2) (KB4013106) - 13.0.4422.0 (X64)
2017 年 3 月 6 日 14:18:16 版权所有 (c) Microsoft Corporation Enterprise Edition（64 位），Windows Server 2012 R2 Standard 6.3（Build 9600） :)（管理程序）

但是白色问号是什么意思？

当我刷新时，这些图标不会消失。我是 sql server 内部的 sysadmin，外部我是那个盒子的管理员。

我注意到的另一件事，你可以在下面的图片中看到。这是 2 个不同的 Management Studio 会话。

在最上面，我以我自己的身份登录DBA and sysadmin，在第二个我使用 Management Studiorun as a different user并使用我用于复制的域帐户，它不是sysadmin.

第二个blue icon在这台服务器和其他服务器中也有，而我的是普通的绿色服务器。

我注意到在运行 SQL Server 2016 SP1 CU6 的服务器上，扩展事件会话有时会显示导致写入的 SELECT 查询。例如：

执行计划没有显示写入的明显原因，例如可能溢出到 TempDB 的哈希表、假脱机或排序：

对 MAX 类型的变量分配或自动统计更新也可能导致这种情况，但在这种情况下都不是写入的原因。

写的东西还来自什么？

我想我曾经在某处读到过写入 tempdb 比不在 tempdb 中的实际表更快。这在任何情况下都是真的吗？我想我记得它说了一些关于 tempdb 并将数据存储在内存中的特殊内容？

作为 ETL 过程的一部分，我们将暂存中的行与报告数据库进行比较，以确定自上次加载数据以来是否有任何列实际发生了更改。

比较基于表的唯一键和所有其他列的某种散列。我们目前使用HASHBYTES该SHA2_256算法，并发现如果许多并发工作线程都在调用HASHBYTES.

在 96 核服务器上进行测试时，以每秒哈希数衡量的吞吐量不会增加超过 16 个并发线程。我通过将并发MAXDOP 8查询的数量从 1更改为12 来进行测试。测试MAXDOP 1显示了相同的可扩展性瓶颈。

作为一种解决方法，我想尝试 SQL CLR 解决方案。这是我试图说明要求的尝试：

• 该函数必须能够参与并行查询
• 函数必须是确定性的
• 该函数必须接受一个NVARCHAR或VARBINARY字符串的输入（所有相关列都连接在一起）
• 字符串的典型输入大小为 100 - 20000 个字符。20000 不是最大值
• 哈希冲突的几率应该大致等于或优于 MD5 算法。CHECKSUM对我们不起作用，因为冲突太多。
• 该函数必须在大型服务器上很好地扩展（每个线程的吞吐量不应随着线程数量的增加而显着降低）

对于 Application Reasons™，假设我无法保存报告表的哈希值。这是一个不支持触发器或计算列的 CCI（还有其他我不想讨论的问题）。

HASHBYTES使用 SQL CLR 函数进行模拟的可扩展方式是什么？我的目标可以表示为在大型服务器上每秒获得尽可能多的哈希值，因此性能也很重要。我对 CLR 很糟糕，所以我不知道如何做到这一点。如果它激励任何人回答，我计划尽快为这个问题添加赏金。下面是一个示例查询，它非常粗略地说明了用例：

DROP TABLE IF EXISTS #CHANGED_IDS;

SELECT stg.ID INTO #CHANGED_IDS
FROM (
    SELECT ID,
    CAST( HASHBYTES ('SHA2_256', 
        CAST(FK1 AS NVARCHAR(19)) + 
        CAST(FK2 AS NVARCHAR(19)) …

由于自 SQL Server 2005 或 2008 年以来，Microsoft 使 SQL Server 版本升级更加频繁，因此许多公司发现很难确定何时升级是“必须的”！当升级是“很高兴”时

本着一些较早的问题的精神，询问为什么更喜欢各种较新版本的 SQL Server 而不是以前的版本，公司可能会考虑将 SQL Server 2016 升级到较早版本甚至更高版本的客观技术或业务原因是什么？发布如 SQL Server 2014？

（这个关于 SQL Server 2012 与 SQL Server 2008 相比的问题，或者这个关于 SQL Server 2012 与 SQL Server 2005 相比的问题，作为这个问题精神的例子浮现在脑海中。他们的答案还扩展了这里的一些原因从 SQL Server 2008 或 SQL Server 2005 开始的公司）

我正在测试从聚集列存储索引中删除数据。

我注意到执行计划中有一个很大的eager spool操作符：

这完成了以下特征：

• 删除了 6000 万行
• 使用 1.9 GiB TempDB
• 14分钟执行时间
• 系列计划
• 1 重新绑定在线轴
• 预计扫描费用：364.821

如果我欺骗估算器低估，我会得到一个更快的计划，避免使用 TempDB：

预计扫描成本：56.901

（这是一个估计的计划，但评论中的数字是正确的。）

有趣的是，如果我通过运行以下命令刷新增量存储，线轴会再次消失：

ALTER INDEX IX_Clustered ON Fact.RecordedMetricsDetail REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON);

只有当增量存储中的页面超过某个阈值时才会引入假脱机。

为了检查增量存储的大小，我正在运行以下查询来检查表的行内页：

SELECT  
  SUM([in_row_used_page_count]) AS in_row_used_pages,
  SUM(in_row_data_page_count) AS in_row_data_pages
FROM sys.[dm_db_partition_stats] as pstats
JOIN sys.partitions AS p
ON pstats.partition_id = p.partition_id
WHERE p.[object_id] = OBJECT_ID('Fact.RecordedMetricsDetail');

第一个计划中的假脱机迭代器是否有任何合理的好处？我不得不假设它是为了提高性能而不是为了万圣节保护，因为它的存在不一致。

我正在 2016 CTP 3.1 上对此进行测试，但我在 2014 SP1 CU3 上看到了相同的行为。

我已经发布了一个生成模式和数据的脚本，并指导您在此处演示问题。

这个问题主要是出于对优化器此时行为的好奇，因为我有一个解决方法来解决引发这个问题的问题（一个大的 spool 填充了 TempDB）。我现在通过使用分区切换来删除。

我遇到了一些SELECT DISTINCT TOP N查询，这些查询似乎被 SQL Server 查询优化器优化得很差。让我们从一个简单的例子开始：具有两个交替值的百万行表。我将使用GetNums函数来生成数据：

DROP TABLE IF EXISTS X_2_DISTINCT_VALUES;

CREATE TABLE X_2_DISTINCT_VALUES (PK INT IDENTITY (1, 1), VAL INT NOT NULL);

INSERT INTO X_2_DISTINCT_VALUES WITH (TABLOCK) (VAL)
SELECT N % 2
FROM dbo.GetNums(1000000);

UPDATE STATISTICS X_2_DISTINCT_VALUES WITH FULLSCAN;

对于以下查询：

SELECT DISTINCT TOP 2 VAL
FROM X_2_DISTINCT_VALUES
OPTION (MAXDOP 1);

SQL Server 可以通过扫描表的第一个数据页找到两个不同的值，但它会扫描所有数据。为什么 SQL Server 不进行扫描，直到找到所需数量的不同值？

对于这个问题，请使用以下测试数据，其中包含 1000 万行，并在块中生成 10 个不同的值：

DROP TABLE IF EXISTS X_10_DISTINCT_HEAP;

CREATE TABLE X_10_DISTINCT_HEAP (VAL VARCHAR(10) NOT …